| Message ID | ECD795A0-4612-4071-B834-7886FBABED7F@dell.com |
|---|---|
| State | New |
| Headers | show |
Oops. Apologies, I submitted a patch against 4.5.1 when I meant to submit a patch against trunk. Please ignore this, I will submit the correct one instead. (Comments welcome in the meantime, of course). paul On Dec 3, 2010, at 11:19 AM, Paul Koning wrote: > This patch fixes failures of libstdc++ to configure when cross-building to NetBSD target. The issue is that there are two places that do link tests, which are disallowed in cross builds. The libtool.m4 change supplies values for netbsd similar to what's already done for selected other targets. The patch to libstdc++-v3/acinclude.m4 lets configure rely on the ld version number to determine support for --gc-sections if a cross-build is being done, rather than doing a double-check. > > Ok to commit? > > ChangeLog (top level): > > 2010-12-03 Paul Koning <paul_koning@dell.com> > > * configure.ac (LT_SYS_DLOPEN_SELF): Add settings for NetBSD. > > ChangeLog (libstdc++-v3): > > 2010-12-03 Paul Koning <paul_koning@dell.com> > > * acinclude.m4 (GLIBCXX_CHECK_LINKER_FEATURES): Don't double-check > --gc-sections support if cross-build. > > Index: gcc-4.5.1/libtool.m4 > =================================================================== > --- gcc-4.5.1/libtool.m4 (revision 147400) > +++ gcc-4.5.1/libtool.m4 (working copy) > @@ -1715,6 +1715,11 @@ > lt_cv_dlopen_self=yes > ;; > > + netbsd*) > + lt_cv_dlopen="dlopen" > + lt_cv_dlopen_libs= > + ;; > + > mingw* | pw32* | cegcc*) > lt_cv_dlopen="LoadLibrary" > lt_cv_dlopen_libs= > Index: gcc-4.5.1/libstdc++-v3/acinclude.m4 > =================================================================== > --- gcc-4.5.1/libstdc++-v3/acinclude.m4 (revision 147400) > +++ gcc-4.5.1/libstdc++-v3/acinclude.m4 (working copy) > @@ -230,7 +230,8 @@ > glibcxx_have_gc_sections=yes > fi > fi > - if test "$glibcxx_have_gc_sections" = "yes"; then > + if test "$glibcxx_have_gc_sections" = "yes" && > + test x$gcc_no_link != xyes; then > # Sufficiently young GNU ld it is! Joy and bunny rabbits! > # NB: This flag only works reliably after 2.16.1. Configure tests > # for this are difficult, so hard wire a value that should work. >
On 12/03/2010 05:19 PM, Paul Koning wrote: > This patch fixes failures of libstdc++ to configure when cross-building to NetBSD target. The issue is that there are two places that do link tests, which are disallowed in cross builds. The libtool.m4 change supplies values for netbsd similar to what's already done for selected other targets. The patch to libstdc++-v3/acinclude.m4 lets configure rely on the ld version number to determine support for --gc-sections if a cross-build is being done, rather than doing a double-check. > > Ok to commit? > Please always diff vs current mainline first, don't diff vs releases. Also, libstdc++ patches also go to the libstdc++ mailing list. Paolo and Ralf, could you have a look? Thanks in advance. Paolo.
On Fri, 3 Dec 2010, Paul Koning wrote: > Index: gcc-4.5.1/libtool.m4 > =================================================================== > --- gcc-4.5.1/libtool.m4 (revision 147400) > +++ gcc-4.5.1/libtool.m4 (working copy) > @@ -1715,6 +1715,11 @@ > lt_cv_dlopen_self=yes > ;; > > + netbsd*) > + lt_cv_dlopen="dlopen" > + lt_cv_dlopen_libs= > + ;; > + libtool patches need to go to upstream libtool first. Is this a backport from upstream? > @@ -230,7 +230,8 @@ > glibcxx_have_gc_sections=yes > fi > fi > - if test "$glibcxx_have_gc_sections" = "yes"; then > + if test "$glibcxx_have_gc_sections" = "yes" && > + test x$gcc_no_link != xyes; then Please explain why this is needed for your target when it isn't needed by other people building for bare-metal targets that cannot link at this point. (In any case, I think NetBSD, like GNU/Linux, *should* be a target where building libstdc++ requires the ability to run link tests. That is, you should need to build libc in your sysroot with a C-only compiler before building one supporting C++, and all the AC_DEFINE settings in crossconfig.m4 for particular functions should be replaced with calls to the appropriate configure test macros.)
On Dec 3, 2010, at 11:56 AM, Joseph S. Myers wrote: > On Fri, 3 Dec 2010, Paul Koning wrote: > >> Index: gcc-4.5.1/libtool.m4 >> =================================================================== >> --- gcc-4.5.1/libtool.m4 (revision 147400) >> +++ gcc-4.5.1/libtool.m4 (working copy) >> @@ -1715,6 +1715,11 @@ >> lt_cv_dlopen_self=yes >> ;; >> >> + netbsd*) >> + lt_cv_dlopen="dlopen" >> + lt_cv_dlopen_libs= >> + ;; >> + > > libtool patches need to go to upstream libtool first. Is this a backport > from upstream? No, it's a pilot error, supplying the wrong patch. > >> @@ -230,7 +230,8 @@ >> glibcxx_have_gc_sections=yes >> fi >> fi >> - if test "$glibcxx_have_gc_sections" = "yes"; then >> + if test "$glibcxx_have_gc_sections" = "yes" && >> + test x$gcc_no_link != xyes; then > > Please explain why this is needed for your target when it isn't needed > by other people building for bare-metal targets that cannot link at this > point. > > (In any case, I think NetBSD, like GNU/Linux, *should* be a target where > building libstdc++ requires the ability to run link tests. That is, you > should need to build libc in your sysroot with a C-only compiler before > building one supporting C++, and all the AC_DEFINE settings in > crossconfig.m4 for particular functions should be replaced with calls to > the appropriate configure test macros.) I need to dig deeper. I thought I understood well enough what's going on, but you're raising questions that go beyond my understanding of cross-builds. So cancel the request for now, if I still have something to propose later I will reopen the question. Thanks for the feedback. paul
* Paul Koning wrote on Fri, Dec 03, 2010 at 06:05:10PM CET: > > I need to dig deeper. I thought I understood well enough what's going on, but you're raising questions that go beyond my understanding of cross-builds. > > So cancel the request for now, if I still have something to propose later I will reopen the question. See http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at I don't have time to pursue this before Sunday, but there's a GCC PR that tracks this: in the no-link case, GCC configury needs to seed a number of cached variables so that Libtool tests aren't run. If the one you're hitting isn't exposed in the test code above, then we need to fix Libtool, too. Otherwise, the libtool.m4 code shouldn't need changing (IIRC). Thanks, Ralf
Index: gcc-4.5.1/libtool.m4 =================================================================== --- gcc-4.5.1/libtool.m4 (revision 147400) +++ gcc-4.5.1/libtool.m4 (working copy) @@ -1715,6 +1715,11 @@ lt_cv_dlopen_self=yes ;; + netbsd*) + lt_cv_dlopen="dlopen" + lt_cv_dlopen_libs= + ;; + mingw* | pw32* | cegcc*) lt_cv_dlopen="LoadLibrary" lt_cv_dlopen_libs= Index: gcc-4.5.1/libstdc++-v3/acinclude.m4 =================================================================== --- gcc-4.5.1/libstdc++-v3/acinclude.m4 (revision 147400) +++ gcc-4.5.1/libstdc++-v3/acinclude.m4 (working copy) @@ -230,7 +230,8 @@ glibcxx_have_gc_sections=yes fi fi - if test "$glibcxx_have_gc_sections" = "yes"; then + if test "$glibcxx_have_gc_sections" = "yes" && + test x$gcc_no_link != xyes; then # Sufficiently young GNU ld it is! Joy and bunny rabbits! # NB: This flag only works reliably after 2.16.1. Configure tests # for this are difficult, so hard wire a value that should work.