Patchwork [RFA] Fix libstdc++ configure failure on cross-builds

login
register
mail settings
Submitter Paul Koning
Date Dec. 3, 2010, 4:19 p.m.
Message ID <ECD795A0-4612-4071-B834-7886FBABED7F@dell.com>
Download mbox | patch
Permalink /patch/74162/
State New
Headers show

Comments

Paul Koning - Dec. 3, 2010, 4:19 p.m.
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.
Paul Koning - Dec. 3, 2010, 4:22 p.m.
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.
>
Paolo Carlini - Dec. 3, 2010, 4:26 p.m.
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.
Joseph S. Myers - Dec. 3, 2010, 4:56 p.m.
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.)
Paul Koning - Dec. 3, 2010, 5:05 p.m.
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
Ralf Wildenhues - Dec. 3, 2010, 5:54 p.m.
* 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

Patch

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.