Patchwork [build,doc,v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

login
register
mail settings
Submitter Rainer Orth
Date July 2, 2010, 11:46 a.m.
Message ID <yddy6duhzsp.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
Download mbox | patch
Permalink /patch/57652/
State New
Headers show

Comments

Rainer Orth - July 2, 2010, 11:46 a.m.
Paolo Carlini <paolo.carlini@oracle.com> writes:

>> Rainer, are you *sure* that HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>> is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
>> Because I did a quick build on x86_64-linux and inside the libstdc++-v3
>> build dir I only see
>> _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
>> config.h + _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>> in c++config.h. Something seems fishy...
>>   
> And abi_check fails. Something is badly wrong on linux. Of course always
> test on linux too when testing this kind of change!!!! Please fix
> quickly or revert, thanks.

I think I see now what's going on.  The following patch should fix it:

* There was a syntax error in acinclude.m4: a missing ;; in the default
  case.

* I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while the
  files under src include c++config.h which adds another level of
  prefixing.

Could you please test this for me?  I don't have ready access to
GNU/Linux.

Sorry for the mess.

	Rainer
IainS - July 2, 2010, 12:03 p.m.
I've just got a bootstrap fail on  i686-apple-darwin9 with :

make[3]: *** No rule to make target `/GCC/gcc-live-trunk/libssp/../ 
contrib/make_sunver.pl', needed by `ssp.map-sun'.  Stop.

same issue... or different?
cheers,
Iain


On 2 Jul 2010, at 12:46, Rainer Orth wrote:

> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
>>> Rainer, are you *sure* that  
>>> HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>>> is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
>>> Because I did a quick build on x86_64-linux and inside the libstdc+ 
>>> +-v3
>>> build dir I only see
>>> _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
>>> config.h +  
>>> _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>>> in c++config.h. Something seems fishy...
>>>
>> And abi_check fails. Something is badly wrong on linux. Of course  
>> always
>> test on linux too when testing this kind of change!!!! Please fix
>> quickly or revert, thanks.
>
> I think I see now what's going on.  The following patch should fix it:
>
> * There was a syntax error in acinclude.m4: a missing ;; in the  
> default
>  case.
>
> * I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while  
> the
>  files under src include c++config.h which adds another level of
>  prefixing.
>
> Could you please test this for me?  I don't have ready access to
> GNU/Linux.
>
> Sorry for the mess.
>
> 	Rainer
>
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2010-07-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
>
> 	* acinclude.m4 (symvers_renaming): Define
> 	HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT instead of
> 	_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT.
> 	Fix syntax error.
> 	* config.h.in: Regenerate.
> 	* configure: Regenerate.
>
> diff -r 08cc828c8afb libstdc++-v3/acinclude.m4
> --- a/libstdc++-v3/acinclude.m4	Mon Jun 28 16:33:40 2010 +0200
> +++ b/libstdc++-v3/acinclude.m4	Fri Jul 02 13:43:56 2010 +0200
> @@ -2998,9 +2998,9 @@
>        symvers_renaming=no  ;;
>      # Other platforms with GNU symbol versioning (GNU/Linux, more?)  
> do.
>      *)
> -        
> AC_DEFINE(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
> +       AC_DEFINE(HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
>          [Define to 1 if the target runtime linker supports binding  
> the same symbol to different versions.])
> -       symvers_renaming=yes
> +       symvers_renaming=yes  ;;
>     esac
> fi
> GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SOL2, test $symvers_renaming = no)
Paolo Carlini - July 2, 2010, 12:05 p.m.
Hi,
> I think I see now what's going on. The following patch should fix it:
> * There was a syntax error in acinclude.m4: a missing ;; in the default
>   case.
>
> * I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while the
>   files under src include c++config.h which adds another level of
>   prefixing.
>
> Could you please test this for me?  I don't have ready access to
> GNU/Linux.
>   
The patch apparently works, I'm finishing regtesting it but abi_check is
back to normality.
> Sorry for the mess.
>   
No problem, your contribution is certainly welcome, but please, in the
future, make sure to *somehow* test on linux too, where versioning s vital.

Thanks,
Paolo.
Paolo Carlini - July 2, 2010, 12:08 p.m.
On 07/02/2010 02:03 PM, IainS wrote:
> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>
> make[3]: *** No rule to make target
> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
> `ssp.map-sun'.  Stop.
>
> same issue... or different?
Different, I would say: evidently you are simply missing make_sunver.pl,
which you can easily get with an svn update.

Paolo.
IainS - July 2, 2010, 12:12 p.m.
On 2 Jul 2010, at 13:08, Paolo Carlini wrote:

> On 07/02/2010 02:03 PM, IainS wrote:
>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>
>> make[3]: *** No rule to make target
>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>> `ssp.map-sun'.  Stop.
>>
>> same issue... or different?
> Different, I would say: evidently you are simply missing  
> make_sunver.pl,
> which you can easily get with an svn update.

Ah, I see just a fluke ... I happened to hit the revision between your  
commits.
Will re-try the bootstrap.
cheers,
Iain
Rainer Orth - July 2, 2010, 12:17 p.m.
Hi Paolo,

>> Could you please test this for me?  I don't have ready access to
>> GNU/Linux.
>>   
> The patch apparently works, I'm finishing regtesting it but abi_check is
> back to normality.

let me know when you're done and I'll commit it.

>> Sorry for the mess.
>>   
> No problem, your contribution is certainly welcome, but please, in the
> future, make sure to *somehow* test on linux too, where versioning s vital.

Ok, I'll see what I can do with either VirtualBox or the test farm.

	Rainer
Rainer Orth - July 2, 2010, 12:22 p.m.
Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 07/02/2010 02:03 PM, IainS wrote:
>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>
>> make[3]: *** No rule to make target
>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>> `ssp.map-sun'.  Stop.
>>
>> same issue... or different?
> Different, I would say: evidently you are simply missing make_sunver.pl,
> which you can easily get with an svn update.

The file should have been committed with the libstdc++ sunver patch,
which went in before the libssp one, but somehow escaped me.  I've
comitted as soon as I noticed.

On the other hand, that script should only be used if
LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.

Could you please check the configure output for `whether symbol
versioning is supported'?  It should be no on Darwin.  Otherwise, please
have a look at libssp/config.log to see what's going on there.

	Rainer
IainS - July 2, 2010, 12:26 p.m.
On 2 Jul 2010, at 13:22, Rainer Orth wrote:

> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
>> On 07/02/2010 02:03 PM, IainS wrote:
>>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>>
>>> make[3]: *** No rule to make target
>>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>>> `ssp.map-sun'.  Stop.
>>>
>>> same issue... or different?
>> Different, I would say: evidently you are simply missing  
>> make_sunver.pl,
>> which you can easily get with an svn update.
>
> The file should have been committed with the libstdc++ sunver patch,
> which went in before the libssp one, but somehow escaped me.  I've
> comitted as soon as I noticed.
>
> On the other hand, that script should only be used if
> LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.

indeed .

> Could you please check the configure output for `whether symbol
> versioning is supported'?  It should be no on Darwin.  Otherwise,  
> please
> have a look at libssp/config.log to see what's going on there.

bootstrap is running with 161706, do I need to apply the patch at:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
?

cheers,
Iain
Rainer Orth - July 2, 2010, 12:29 p.m.
IainS <developer@sandoe-acoustics.co.uk> writes:

>> On the other hand, that script should only be used if
>> LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.
>
> indeed .

That's bad.  I suppose the Darwin ld either silently accepts/ignores -M
or it has a different meaning there which happens to have no ill effect.

>> Could you please check the configure output for `whether symbol
>> versioning is supported'?  It should be no on Darwin.  Otherwise, please
>> have a look at libssp/config.log to see what's going on there.
>
> bootstrap is running with 161706, do I need to apply the patch at:
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html

Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
AFAIK.

	Rainer
Paolo Carlini - July 2, 2010, 12:34 p.m.
On 07/02/2010 02:29 PM, Rainer Orth wrote:
>> bootstrap is running with 161706, do I need to apply the patch at:
>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>     
The patch is already in.
> Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
> AFAIK.
>   
But note that lately Darwin has some sort of versioning, I don't know
the details. I think we should be careful here, and make sure we really
enable the new machinery on *solaris and solaris only* in a very direct
and active way.

Paolo.
IainS - July 2, 2010, 12:39 p.m.
On 2 Jul 2010, at 13:29, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>>> On the other hand, that script should only be used if
>>> LIBSSP_USE_SYMVER_SUN, which has no business being defined on  
>>> Darwin.
>>
>> indeed .
>
> That's bad.  I suppose the Darwin ld either silently accepts/ignores  
> -M
> or it has a different meaning there which happens to have no ill  
> effect.

hm darwin more usually  barfs on things - unless they are BSD  
compatibility flags...

I don't know exactly what you're trying to achieve...
... Darwin has it's own library versioning system, but not symbol  
versioning, per se
[I guess it could be achieved with two-level namespaces, but I don't  
think anyone is proposing to add that to darwin's gcc port at the  
moment].

the manual pages for Darwin ld:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html

>>> Could you please check the configure output for `whether symbol
>>> versioning is supported'?  It should be no on Darwin.  Otherwise,  
>>> please
>>> have a look at libssp/config.log to see what's going on there.
>>
>> bootstrap is running with 161706, do I need to apply the patch at:
>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>
> Shouldn't be necessary since Darwin has no GNU-style symbol  
> versioning,
> AFAIK.

OK.   I'll let you know how it goes :)
Iain
Rainer Orth - July 2, 2010, 12:43 p.m.
Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 07/02/2010 02:29 PM, Rainer Orth wrote:
>>> bootstrap is running with 161706, do I need to apply the patch at:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>>     
> The patch is already in.

Ok, thanks.

>> Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
>> AFAIK.
>>   
> But note that lately Darwin has some sort of versioning, I don't know
> the details. I think we should be careful here, and make sure we really
> enable the new machinery on *solaris and solaris only* in a very direct
> and active way.

Indeed, though AFAICS only in libstdc++.  I have been extra careful to
enable Sun symbol versioning only for Solaris in libstdc++:

@@ -2834,6 +2837,20 @@
       case ${target_os} in
         darwin*)
 	  enable_symvers=darwin ;;
+	# Sun symbol versioning exists since Solaris 2.5.
+	solaris2.[[5-9]]* | solaris2.1[[0-9]]*)
+	  # make_sunver.pl needs GNU c++filt to support extern "C++" in
+	  # version scripts, so disable symbol versioning if none can be
+	  # found.
+	  if test -z "$ac_cv_path_CXXFILT"; then
+	    AC_MSG_WARN([=== You have requested Sun symbol versioning, but])
+	    AC_MSG_WARN([=== no GNU c++filt could  be found.])
+	    AC_MSG_WARN([=== Symbol versioning will be disabled.])
+	    enable_symvers=no
+	  else
+	    enable_symvers=sun
+	  fi
+	  ;;
         *)
           enable_symvers=no ;;
       esac

On the other hand, in libssp I simply check if

$ gcc -fPIC -shared -Wl,-M,./conftest.map

works.  It seems that it appears to do so on Darwin, though either with
no or with a different effect than expected.

That's the current mess with the different symbol versioning checks in
libstdc++-v3, libgomp, libgfortran, libssp, and libjava.

I meant to fix this and posted about the problem back in February

	http://gcc.gnu.org/ml/gcc/2010-02/msg00342.html

but that message met with deafening silence ;-(  I still plan to unify
this somehow, at least for GCC, but wanted to get something in for 4.6.

	Rainer
Rainer Orth - July 2, 2010, 12:51 p.m.
IainS <developer@sandoe-acoustics.co.uk> writes:

>> That's bad.  I suppose the Darwin ld either silently accepts/ignores -M
>> or it has a different meaning there which happens to have no ill effect.
>
> hm darwin more usually  barfs on things - unless they are BSD compatibility
> flags...

This may be the 4.3BSD -M option to produce a load map, but that doesn't
take an option argument and isn't listed on the ld(1) man page you cite.

> I don't know exactly what you're trying to achieve...
> ... Darwin has it's own library versioning system, but not symbol
> versioning, per se

This is not about library versioning at all, but for libstdc++.so only,
there's already libstdc++-v3/scripts/make_exports.pl for Darwin (in
fact, that script is the parent of make_sunver.pl) that creates an
export list, this way at least hiding all global symbols that are not
supposed to be exported.

	Rainer
IainS - July 2, 2010, 12:53 p.m.
On 2 Jul 2010, at 13:39, IainS wrote:

>>>> Could you please check the configure output for `whether symbol
>>>> versioning is supported'?  It should be no on Darwin.  Otherwise,  
>>>> please
>>>> have a look at libssp/config.log to see what's going on there.
>>>
>>> bootstrap is running with 161706, do I need to apply the patch at:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>
>> Shouldn't be necessary since Darwin has no GNU-style symbol  
>> versioning,
>> AFAIK.
>
> OK.   I'll let you know how it goes :)

hm, not good:
chk.o \
          `echo  | \
             sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
          > ssp.map-sun || (rm -f ssp.map-sun ; exit 1)
nm: no name list
unknown nm output ___guard_setup t 110 0 at /GCC/gcc-live-trunk/ 
libssp/../contrib/make_sunver.pl line 69, <NM> line 4.
make[2]: *** [ssp.map-sun] Error 1

===

I look in libssp at config.log [m32 and m64] and see:

configure:4126: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
GCC/gcc-4-
6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-install/i686- 
apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-apple-darwin9/ 
sys-in
clude    -o conftest -g -O2   -fPIC -shared -Wl,--version-script,./ 
conftest.map conftest.c  >&5
ld: unknown option: --version-script
collect2: ld returned 1 exit status
configure:4126: $? = 1

but no other references to "symbol" that have any bearing..
so perhaps the test is not being run at all for Darwin?

Iain
Rainer Orth - July 2, 2010, 12:58 p.m.
IainS <developer@sandoe-acoustics.co.uk> writes:

> hm, not good:
> chk.o \
>          `echo  | \
>             sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
>          > ssp.map-sun || (rm -f ssp.map-sun ; exit 1)
> nm: no name list
> unknown nm output ___guard_setup t 110 0 at /GCC/gcc-live-trunk/
> libssp/../contrib/make_sunver.pl line 69, <NM> line 4.
> make[2]: *** [ssp.map-sun] Error 1

but sort of expected: this has no business being run on anything but Solaris.

> I look in libssp at config.log [m32 and m64] and see:
>
> configure:4126: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
> GCC/gcc-4-
> 6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-install/i686-
> apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-apple-darwin9/
> sys-in
> clude    -o conftest -g -O2   -fPIC -shared -Wl,--version-script,./
> conftest.map conftest.c  >&5
> ld: unknown option: --version-script
> collect2: ld returned 1 exit status
> configure:4126: $? = 1

This is the first test for GNU ld --version-script, which obviously
fails.

> but no other references to "symbol" that have any bearing..
> so perhaps the test is not being run at all for Darwin?

Sure it is, otherwise you wouldn't see Sun-style symbol versioning being
enabled.  The next test with

gcc -fPIC -shared -Wl,-M,./conftest.map

is the interesting one.  What happens there?  And please provide the
relevant output fragment of the libssp configure run, too.

Thanks.
	Rainer
IainS - July 2, 2010, 1:01 p.m.
On 2 Jul 2010, at 13:51, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>>> That's bad.  I suppose the Darwin ld either silently accepts/ 
>>> ignores -M
>>> or it has a different meaning there which happens to have no ill  
>>> effect.
>>
>> hm darwin more usually  barfs on things - unless they are BSD  
>> compatibility
>> flags...
>
> This may be the 4.3BSD -M option to produce a load map, but that  
> doesn't
> take an option argument and isn't listed on the ld(1) man page you  
> cite.

let me know what you want to test - and I'll give it a whirl..

>> I don't know exactly what you're trying to achieve...
>> ... Darwin has it's own library versioning system, but not symbol
>> versioning, per se
>
> This is not about library versioning at all, but for libstdc++.so  
> only,
> there's already libstdc++-v3/scripts/make_exports.pl for Darwin (in
> fact, that script is the parent of make_sunver.pl) that creates an
> export list, this way at least hiding all global symbols that are not
> supposed to be exported.

Ah yes, I remember looking at that ..
.. it would be good to update it to deal with Darwin's _eh situation
(removing the _eh exports, which should not be coalescable AFAICS ,at  
least for darwin >= 9).

(I also suspect that there are some wrong visibilities too - from some  
testing I did with the static-libstdc++ ... but I've not looked at it  
in several months).

time, as ever, is the short commodity.

Iain.
IainS - July 2, 2010, 1:20 p.m.
On 2 Jul 2010, at 13:58, Rainer Orth wrote:

>> but no other references to "symbol" that have any bearing..
>> so perhaps the test is not being run at all for Darwin?
>
> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
> being
> enabled.  The next test with
>
> gcc -fPIC -shared -Wl,-M,./conftest.map
>
> is the interesting one.  What happens there?  And please provide the
> relevant output fragment of the libssp configure run, too.

configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686- 
apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,- 
M,./conftest.map conftest.c  >&5
ld warning: in ./conftest.map, file is not of required architecture
configure:4156: $? = 0
configure:4166: result: sun

hm.  I guess that -M is unrecognized and the linker falls back to it's  
default which is to expect the remaining items to be objects - which,  
of course, the ma file is not.  However, since the link does not  
actually fail - I guess it only reports a warning.

Iain.
IainS - July 2, 2010, 1:28 p.m.
On 2 Jul 2010, at 14:20, IainS wrote:

>
> On 2 Jul 2010, at 13:58, Rainer Orth wrote:
>
>>> but no other references to "symbol" that have any bearing..
>>> so perhaps the test is not being run at all for Darwin?
>>
>> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
>> being
>> enabled.  The next test with
>>
>> gcc -fPIC -shared -Wl,-M,./conftest.map
>>
>> is the interesting one.  What happens there?  And please provide the
>> relevant output fragment of the libssp configure run, too.
>
> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
> i686-apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared  
> -Wl,-M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to  
> it's default which is to expect the remaining items to be objects -  
> which, of course, the ma file is not.  However, since the link does  
> not actually fail - I guess it only reports a warning

As an aside, I wonder if the autoconfigury/libtool people have already  
resolved all these issues?
Iain
IainS - July 2, 2010, 1:41 p.m.
On 2 Jul 2010, at 14:20, IainS wrote:

> On 2 Jul 2010, at 13:58, Rainer Orth wrote:
>
>>> but no other references to "symbol" that have any bearing..
>>> so perhaps the test is not being run at all for Darwin?
>>
>> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
>> being
>> enabled.  The next test with
>>
>> gcc -fPIC -shared -Wl,-M,./conftest.map
>>
>> is the interesting one.  What happens there?  And please provide the
>> relevant output fragment of the libssp configure run, too.
>
> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
> i686-apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared  
> -Wl,-M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to  
> it's default which is to expect the remaining items to be objects -  
> which, of course, the ma file is not.  However, since the link does  
> not actually fail - I guess it only reports a warning.

from ld (tools version 2.5) manual page linked earlier:
-M (32-bit only) Produce a load map, listing all the segments and  
sections. The list includes the address where each input file's  
section appears in the output file, as well as the section's size.  
This option overlaps with a compiler option. If you use the compiler  
driver cc(1) to invoke ld, invoke this option in this way: -Wl,-M.
so, although it's not listed in the 3.2.x tools, I imagine that it is  
silently ignored for backward-compatibility.

Iain.
Rainer Orth - July 2, 2010, 3:20 p.m.
IainS <developer@sandoe-acoustics.co.uk> writes:

> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-
> apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,-
> M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to it's
> default which is to expect the remaining items to be objects - which,  of
> course, the ma file is not.  However, since the link does not  actually
> fail - I guess it only reports a warning.

I've seen similar behavior in the SGI ld which warns about an unknown
option, but still exits with 0.

	Rainer
Rainer Orth - July 2, 2010, 3:22 p.m.
IainS <developer@sandoe-acoustics.co.uk> writes:

> As an aside, I wonder if the autoconfigury/libtool people have already
> resolved all these issues?

They have, but only halfheartedly: they provide AC_LANG_WERROR, but no
way to turn that flag off again.  That's what I used to work around the
libjava testsuite failures on IRIX 6.5:

	http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01889.html

	Rainer
IainS - July 2, 2010, 3:26 p.m.
On 2 Jul 2010, at 16:20, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
>> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
>> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-
>> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
>> i686-
>> apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,-
>> M,./conftest.map conftest.c  >&5
>> ld warning: in ./conftest.map, file is not of required architecture
>> configure:4156: $? = 0
>> configure:4166: result: sun
>>
>> hm.  I guess that -M is unrecognized and the linker falls back to  
>> it's
>> default which is to expect the remaining items to be objects -  
>> which,  of
>> course, the ma file is not.  However, since the link does not   
>> actually
>> fail - I guess it only reports a warning.
>
> I've seen similar behavior in the SGI ld which warns about an unknown
> option, but still exits with 0.

Darwin's ld will exit with an error message and status = 1 for an  
unrecognized option.

In this case, as I indicated in a follow-up mail, the "-M" option is  
valid for toolsets that are current in darwin 8 (still supported by  
gcc, AFAIK) and silently ignored in toolsets for darwin 9 (at least)  
and probably darwin 10.

so, we need a different discriminator.

cheers,
Iain
Ralf Wildenhues - July 5, 2010, 5:52 a.m.
Hello Rainer,

* Rainer Orth wrote on Fri, Jul 02, 2010 at 02:43:06PM CEST:
> I meant to fix this and posted about the problem back in February
> 
> 	http://gcc.gnu.org/ml/gcc/2010-02/msg00342.html
> 
> but that message met with deafening silence ;-(  I still plan to unify
> this somehow, at least for GCC, but wanted to get something in for 4.6.

I'm sorry about the silence regarding having this in Libtool, or
unifying somehow.  I think you are right, that would be a good idea.
I also think it can be done later, if that is better for the work
already done.  There is a thread on the libtool list with a related
request, maybe you can offer your opinion there:
<http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2269/focus=10964>

I'm not sure libtool can generally assume perl to be present on end-user
machines.

Wrt. dealing with linkers that ignore switches unknown to them, you
might benefit from the _LT_LINKER_OPTION macro in libtool.m4 which also
takes (differences in) warning output into account when testing.

Hope that helps; I haven't had time to read the rest of this in detail
(still catching up on mail).

Cheers,
Ralf

Patch

diff -r 08cc828c8afb libstdc++-v3/acinclude.m4
--- a/libstdc++-v3/acinclude.m4	Mon Jun 28 16:33:40 2010 +0200
+++ b/libstdc++-v3/acinclude.m4	Fri Jul 02 13:43:56 2010 +0200
@@ -2998,9 +2998,9 @@ 
        symvers_renaming=no  ;;
      # Other platforms with GNU symbol versioning (GNU/Linux, more?) do.
      *)
-       AC_DEFINE(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
+       AC_DEFINE(HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
          [Define to 1 if the target runtime linker supports binding the same symbol to different versions.])
-       symvers_renaming=yes
+       symvers_renaming=yes  ;;
     esac
 fi
 GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SOL2, test $symvers_renaming = no)