| Message ID | yddy6duhzsp.fsf@manam.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
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)
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.
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.
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
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
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
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
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
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.
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
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
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
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
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
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.
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.
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
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.
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
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
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
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
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)