Other components check for --enable-symvers=gnu or --enable-symvers=sun, as well as just yes or no. libgcc/configure{.ac} checks only for yes or no, and if gnu or sun it fails: configure:24535: checking whether ld supports anonymous version scripts configure:24545: error: Unknown argument to enable/disable symvers Code was originally added in PR bootstrap/48135
Meant to say libjava/configure in the previous comment.
Please provide a bit mor information: * what platform are you on? * what are your configure options? * why do you insist on specifying the symvers flavor manually?
(In reply to comment #2) > Please provide a bit mor information: > > * what platform are you on? It happens on every platform I configure, but if you want something specific: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=x86_64-unknown-linux-gnu I also have the same problems on: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=mips64-unknown-linux-gnu and: --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-unknown-linux-gnuspe This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in: http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh > * what are your configure options? --enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib --with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200 --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm -L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib -lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch --with-long-double-128 --enable-gold > * why do you insist on specifying the symvers flavor manually? "I" didn't insist on specifying it manually. crosstool-ng did. While you might say that is a problem with crosstool-ng, but the older crosstool and other cross tool scripts use this as well. If every other component besides libjava specifically check for yes|no|gnu*|sun, why doesn't libjava? Or... If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to support it?
(In reply to comment #3) > (In reply to comment #2) > > Please provide a bit mor information: Sure. Re-reading comment #3, maybe I sounded a bit brass. Let me try again. Yann requested to be CC'd. > > * what platform are you on? > > It happens on every platform I configure, but if you want something specific: > --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu > --target=x86_64-unknown-linux-gnu > > I also have the same problems on: > --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu > --target=mips64-unknown-linux-gnu > > and: > --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > --target=powerpc-unknown-linux-gnuspe same response. > This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in: > http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh > > > * what are your configure options? > > --enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib > --with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200 > --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap > --enable-libgomp --enable-libssp > --with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static > --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm > -L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib > -lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch > --with-long-double-128 --enable-gold Same response. > > * why do you insist on specifying the symvers flavor manually? I had a discussion with Yann E. Morin, and it sounds like this option was ported forward from the legacy options in Dan Kegel's crosstool. The questions I am asking should be: * Should this ever (for any platform) be set manually? Or should this always be an 'automatic' setting? * Isn't it inconsistent that every component checks for 'gnu*' and 'sun', except for libjava? Yann is currently retesting the sh4 build without --enable-symvers=gnu set to see if it still needs it. If it does not, then he will remove it completely, otherwise it should be target specific in crosstool-ng and not for all targets. > "I" didn't insist on specifying it manually. crosstool-ng did. > While you might say that is a problem with crosstool-ng, but the older > crosstool and other cross tool scripts use this as well. > > If every other component besides libjava specifically check for > yes|no|gnu*|sun, why doesn't libjava? > > Or... > > If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to > support it?
>> * why do you insist on specifying the symvers flavor manually? > > "I" didn't insist on specifying it manually. crosstool-ng did. > While you might say that is a problem with crosstool-ng, but the older > crosstool and other cross tool scripts use this as well. > > If every other component besides libjava specifically check for > yes|no|gnu*|sun, why doesn't libjava? Simply because the gnu* vs. sun distinction is immaterial for the version maps used by libjava: anonymous version maps work the same for both flavors, only the on vs. off distinction is important (if at all). > Or... > > If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to > support it? No, because their behavior differs depending no the flavor used. You could probably argue that libjava should accept them for consistencies sake, though. My usual stance on this (especially when I see configure lines with dozens of options): why in hell do people do this? The defaults should work fine for them, and if they don't, I'd like to know about this. In many cases, I'd expect the gcc maintainers to know how to determine sensible defaults. Of course there are exceptions, but unless proven otherwise this doesn't seem to be an instance. Rainer
> Sure. Re-reading comment #3, maybe I sounded a bit brass. No problem, I can stand some heat :-) >> > * why do you insist on specifying the symvers flavor manually? > > I had a discussion with Yann E. Morin, and it sounds like this option was > ported forward from the legacy options in Dan Kegel's crosstool. > > The questions I am asking should be: > > * Should this ever (for any platform) be set manually? Or should this always be > an 'automatic' setting? Except for the (experimental) gnu vs. gnu-versioned-namespace distinction in libstdc++-v3, I don't believe so. We had a case where --disable-symvers/--enable-symvers=no was necessary as a workaround, but otherwise I'd prefer users to leave this alone. Unfortunately, the configure checks in different target libraries are currently inconsistent. I hope to get back to this at some point, though. > * Isn't it inconsistent that every component checks for 'gnu*' and 'sun', > except for libjava? In a way, it is, except that it matters for those components, but not for libjava. But the check should be for gnu and sun alone, gnu-versioned-namespace is probably wrong here. > Yann is currently retesting the sh4 build without --enable-symvers=gnu set to > see if it still needs it. If it does not, then he will remove it completely, > otherwise it should be target specific in crosstool-ng and not for all targets. Excellent, thanks for checking this. Rainer
(In reply to comment #6) > > I had a discussion with Yann E. Morin, and it sounds like this option was > > ported forward from the legacy options in Dan Kegel's crosstool. > > > > The questions I am asking should be: > > > > * Should this ever (for any platform) be set manually? Or should this always be > > an 'automatic' setting? > > Except for the (experimental) gnu vs. gnu-versioned-namespace > distinction in libstdc++-v3, I don't believe so. We had a case where > --disable-symvers/--enable-symvers=no was necessary as a workaround, but > otherwise I'd prefer users to leave this alone. Unfortunately, the > configure checks in different target libraries are currently > inconsistent. I hope to get back to this at some point, though. Ok. Thanks for the explanation! > > * Isn't it inconsistent that every component checks for 'gnu*' and 'sun', > > except for libjava? > > In a way, it is, except that it matters for those components, but not > for libjava. But the check should be for gnu and sun alone, > gnu-versioned-namespace is probably wrong here. > > > Yann is currently retesting the sh4 build without --enable-symvers=gnu set to > > see if it still needs it. If it does not, then he will remove it completely, > > otherwise it should be target specific in crosstool-ng and not for all targets. > > Excellent, thanks for checking this. > > Rainer So, Yann found that sh4 did not need this option anymore, and he has since removed the --enable-symvers option from the build: http://crosstool-ng.org/hg/crosstool-ng/rev/b24ead1a5947 So now we just let gcc figure it out. As for the inconsistent check in libjava and the previous change to remove enable-symvers from ct-ng in mind, this can probably be resolved as invalid unless you'd like to just add gnu|sun to the libjava_cv_anon_version_script=yes;; case. (attaching patch to give an example). wrt all of the extra configuration options, it would be very appreciated if in another thread we could discuss some of them. I'm sure a lot of the options we have for building binutils and gcc are ported forward from the older crosstool scripts and aren't needed anymore. My theory on that has been: if it ain't broke, don't fix it ...until now.
Created attachment 24639 [details] libjava-version_script-consistency.diff
> --- Comment #7 from Bryan Hundven <bryanhundven at gmail dot com> 2011-06-29 19:30:03 UTC --- [...] > So, Yann found that sh4 did not need this option anymore, and he has since > removed the --enable-symvers option from the build: > > http://crosstool-ng.org/hg/crosstool-ng/rev/b24ead1a5947 > > So now we just let gcc figure it out. Excellent, thanks for pursuing this. > As for the inconsistent check in libjava and the previous change to remove > enable-symvers from ct-ng in mind, this can probably be resolved as invalid > unless you'd like to just add gnu|sun to the > libjava_cv_anon_version_script=yes;; case. (attaching patch to give an > example). I'll certainly have a look: perhaps this will prompt me to unify the symbol versioning configure support across all gcc target libraries :-) > wrt all of the extra configuration options, it would be very appreciated if in > another thread we could discuss some of them. I'm sure a lot of the options we > have for building binutils and gcc are ported forward from the older crosstool > scripts and aren't needed anymore. My theory on that has been: if it ain't > broke, don't fix it > ...until now. We can certainly do this, either in private mail or on some mailing list (unless I don't have to subscribe to yet another one :-). Thanks. Rainer
GCC 4.7.0 is being released, adjusting target milestone.
libgcj/libjava has been removed so closing as won't fix