Created attachment 348650 [details] Build log Rebuilding a @system with new 4.7.3 caused a fail on this one package
Created attachment 348652 [details] emerge --info output
checking whether the C compiler works... no configure: error: in `/var/tmp/portage/sys-libs/db-4.8.30/work/db-4.8.30/build_unix': configure: error: C compiler cannot create executables See `config.log' for more details !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-libs/db-4.8.30/work/db-4.8.30/build_unix/config.log Well?
Created attachment 348710 [details] /var/tmp/portage/sys-libs/db-4.8.30/work/db-4.8.30/build_unix/config.log Please find the log attached. Sorry, I prevously had fail-clean set, so this log was wiped away...
You probably set a custom env for sys-libs/db /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: --default-symver: unknown option /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information collect2: error: ld returned 1 exit status And from emerge --info: LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--default-symver"
(In reply to comment #4) > You probably set a custom env for sys-libs/db > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ > ld: --default-symver: unknown option > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ > ld: use the --help option for usage information > collect2: error: ld returned 1 exit status > > And from emerge --info: > LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--default-symver" Hmm, no. I also have this LDFLAGS, but sys-libs/db builds fine. $ emerge --info sys-libs/db | tail -n3 sys-libs/db-4.8.30 was built with the following: LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--default-symver"
This also compiles fine for me with gcc-4.7.3 on amd64: sys-libs/db-4.8.30 was built with the following: USE="(consolekit) cxx java (multilib) (policykit) -doc -examples -tcl -test" ABI_X86="64" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--default-symver"
I look like that I've found a possible source of the issue... which was a "gold" linker I decided to try. I switched back to ld.bfd and the package builded just fine. Therefore I seem to post this bug report to a wrong place, though... Thank you guys for your time!
--default-symver is not something you should be putting in global LDFLAGS. it makes no sense and is probably dangerous.
(In reply to comment #8) > --default-symver is not something you should be putting in global LDFLAGS. > it makes no sense and is probably dangerous. From sys-libs/db ebuild: if use userland_GNU ; then append-ldflags -Wl,--default-symver fi
(In reply to comment #9) doing it on a per-ebuild basis is perfectly fine as the maintainers are auditing it on a per-code base basis to make sure things will work
But shouldn't this bug be reopened and blocking bug 269315?
(In reply to comment #11) > But shouldn't this bug be reopened and blocking bug 269315? Blocking bug 269315 and reopening, obviously the db's ebuild and the 'if userland_GNU && check-if-the-linker-is-gold-or-not...' should be extended for the GNU gold linker
(In reply to comment #12) i don't think we want to do "is this linker XXX". flag-o-matic has support for testing frontends vs flags, so it'd probably make sense to leverage that. i wonder if this would be sufficient: append-ldflags $(test-flags-CC -Wl,--default-symver)
*** Bug 494896 has been marked as a duplicate of this bug. ***
(In reply to SpanKY from comment #13) > (In reply to comment #12) > > i don't think we want to do "is this linker XXX". flag-o-matic has support > for testing frontends vs flags, so it'd probably make sense to leverage that. > > i wonder if this would be sufficient: > append-ldflags $(test-flags-CC -Wl,--default-symver) just FYI, there is a flag to control which linker to use: -fuse-ld=bfd or -fuse-ld=gold... so it is not a problem to "temporarily" switch to BFD (just for sure) for one particular package... it is the way I've workaround this problem (via per package env file)
well, either the flag is serving a purpose, or it isn't. it's odd that we're doing it only for Linux platforms. i don't know the history behind the flag or what it's trying to actually solve though. the changelog is written assuming the reader knows the history: Author: Paul de Vrieze <pauldv@gentoo.org> Date: Wed Feb 22 20:51:59 2006 +0000 Get experimental symbol versions (Portage version: 2.1_pre4-r1) + 22 Feb 2006; Paul de Vrieze <pauldv@gentoo.org> db-4.3.29.ebuild, + db-4.4.20.ebuild: + Add the "--default-symver" linker option. This should be a superior solution + to the uniquename hack. It works with the linker, so no header file + problems, no configure script problems, etc. This might actually finally + solve our db problems ;-). sys-libs/db/db-4.3.29.ebuild: + # Add linker versions to the symbols. Easier to do, and safer than header file + # mumbo jumbo. + if use userland_GNU; then + append-ldflags -Wl,--default-symver + fi
(In reply to Alex Turbov from comment #15) > just FYI, there is a flag to control which linker to use: -fuse-ld=bfd or > -fuse-ld=gold... so it is not a problem to "temporarily" switch to BFD (just > for sure) for one particular package... That's only available with gcc 4.8 and later.
Before I had an package env file, the build failed already in the configure phase with: checking whether the C compiler works... no After creating the env file, the configure phase was successfull, but the compile phase then failed wiuth: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: --default-symver: unknown option /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information The output of libtool states that it got the fuse-ld=bfd option, but the actual link command executed later is missing this option. It looks like libtool is filtering out this option. Changing the line 6304 in build_unix/libtool to: -O*|-flto*|-fwhopr*|-fuse-linker-plugin|-fuse-ld=*) fixes the issue. @Alex: Would you please post your package env file? Here is the content of my env file: LD="/usr/bin/ld.bfd" #needed for ntfs-3g LDFLAGS="${LDFLAFS} -fuse-ld=bfd" and in package.env I added: sys-libs/db ldbfd.conf
(In reply to Steffen Hau from comment #18) > @Alex: > Would you please post your package env file? here is my use-bfd-linker.conf if [ "bfd" != "$(readlink -f `which ld` | sed 's,.*\.\(bfd$\),\1,')" ]; then einfo "Use ld.bfd linker" LDFLAGS="${LDFLAGS} -Wl,-fuse-ld=bfd" fi
(In reply to Alex Turbov from comment #19) > here is my use-bfd-linker.conf > > if [ "bfd" != "$(readlink -f `which ld` | sed 's,.*\.\(bfd$\),\1,')" ]; then > einfo "Use ld.bfd linker" > LDFLAGS="${LDFLAGS} -Wl,-fuse-ld=bfd" > fi !!! Problem in 'sys-libs/db' dependencies. !!! "/etc/portage/env/use-bfd-linker.conf", line 1: Invalid token '[' (not '=') portage.exception ... done! "/etc/portage/env/use-bfd-linker.conf", line 1: Invalid token '[' (not '=')
Also, sys-libs/db does actually build successfully using the gold linker, if you remove the unsupported default-symver ldflag, so surely the correct approach is to modify the logic of "if use userland_GNU" to accommodate the gold linker, rather than falling back to BFD when it isn't actually necessary.
This also affects sys-libs/db-6.0.30::gentoo as seen in the attachment.
Created attachment 379930 [details] Build log Attempted masked version to see if issue persists in other builds.
*** Bug 518056 has been marked as a duplicate of this bug. ***
If there is a proper way - eclass/function/... - to detect the used ld - gold, bfd - and temporariliy switch the symlink it would be useful in other ebuilds too and I'd like to hear it. changing LD= is not an option as it will not work with all package in the tree. Thanks in advanced
I tried using the -fuse-ld=bfd work around, and it didn't work for me, as gcc-4.9.1 really just couldn't handle the --default-symver flag. It appears that somehow libtool is ignoring my best efforts, as detailed in the attachment I'm providing...
Created attachment 390516 [details] Tail end of my build process Notice that the -fuse=ld=bfd line is there multiple times in the first line, but then missing from what libtool echos out.
*** Bug 533070 has been marked as a duplicate of this bug. ***
It seems that Flameeyes hit the problem in 2011 as of the writing on his post: https://blog.flameeyes.eu/2011/06/gold-readiness-obstacle-1-berkeley-db#gsc.tab=0 Apparently, the --default-symver option is the only "easy and painless" way to have the symbols versioned for the libraries (minor library versions) without actually touching anything in the build system. It seems ld.gold did *not* gain the feature in 3 years time, so it's probably fair to assume it won't gain it in the short term. Unless a simpler solution can be devised/implemented, I think forcing the linker to ld.bfd is the only viable option until the feature gets implemented (if ever). I feel that the work required for the right solution is much greater than the one required for this one-liner fix. Side note: I think the title of the bug should be changed to reflect the fact that sys-libs/db does not compile with LD gold *because* --default-symver is explicitly forced in the ebuild.
should be all set now in the tree; thanks for the report! Commit message: Set linker to bfd when gold is detected http://sources.gentoo.org/sys-libs/db/db-4.8.30-r2.ebuild?r1=1.10&r2=1.11 http://sources.gentoo.org/sys-libs/db/db-5.1.29-r1.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-libs/db/db-5.3.28-r2.ebuild?r1=1.3&r2=1.4 http://sources.gentoo.org/sys-libs/db/db-6.0.30-r1.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-libs/db/db-6.1.19.ebuild?r1=1.1&r2=1.2
Created attachment 407838 [details] emerge --info It looks like the fix doesn't work here: configure:5354: checking whether the C compiler works configure:5376: x86_64-pc-linux-gnu-gcc -m32 -march=native -g3 -gdwarf-4 -fvar-tracking-assignments -O2 -pipe -D_GNU_SOURCE -D_REENTRANT -fuse-ld=gold -Wl,-O1 -Wl,--default-symver conftest.c >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld.gold: --default-symver: unknown option