Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 470634 - sys-libs/db-4.8.30 fails when using ld.gold and LDFLAGS='-Wl,-default-symver'
Summary: sys-libs/db-4.8.30 fails when using ld.gold and LDFLAGS='-Wl,-default-symver'
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 494896 518056 533070 (view as bug list)
Depends on:
Blocks: gold-tracker
  Show dependency tree
 
Reported: 2013-05-19 11:31 UTC by Nick
Modified: 2015-11-28 16:51 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Build log (sys-libs:db-4.8.30:20130519-104734.log,5.96 KB, text/plain)
2013-05-19 11:31 UTC, Nick
Details
emerge --info output (db-4.8.30.info,6.10 KB, text/plain)
2013-05-19 11:34 UTC, Nick
Details
/var/tmp/portage/sys-libs/db-4.8.30/work/db-4.8.30/build_unix/config.log (config.log,15.23 KB, text/plain)
2013-05-20 07:00 UTC, Nick
Details
Build log (file_470634.txt,9.48 KB, text/plain)
2014-06-29 16:47 UTC, Isaac ‘Will It Work’ Dansicker
Details
Tail end of my build process (config.log,7.65 KB, text/plain)
2014-11-29 03:15 UTC, Christopher Smith
Details
emerge --info (emerge.info,7.27 KB, text/plain)
2015-07-28 22:56 UTC, Andrei Slavoiu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick 2013-05-19 11:31:52 UTC
Created attachment 348650 [details]
Build log

Rebuilding a @system with new 4.7.3 caused a fail on this one package
Comment 1 Nick 2013-05-19 11:34:30 UTC
Created attachment 348652 [details]
emerge --info output
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2013-05-19 14:05:03 UTC
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?
Comment 3 Nick 2013-05-20 07:00:27 UTC
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...
Comment 4 Alexander Tsoy 2013-05-20 11:14:54 UTC
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"
Comment 5 Alexander Tsoy 2013-05-20 11:17:20 UTC
(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"
Comment 6 Jeremy Murphy 2013-05-21 00:59:56 UTC
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"
Comment 7 Nick 2013-05-21 08:18:47 UTC
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!
Comment 8 SpanKY gentoo-dev 2013-05-21 18:11:10 UTC
--default-symver is not something you should be putting in global LDFLAGS.  it makes no sense and is probably dangerous.
Comment 9 Alexander Tsoy 2013-05-21 18:49:06 UTC
(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
Comment 10 SpanKY gentoo-dev 2013-05-21 21:17:08 UTC
(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
Comment 11 Alexander Tsoy 2013-05-21 23:24:04 UTC
But shouldn't this bug be reopened and blocking bug 269315?
Comment 12 Samuli Suominen (RETIRED) gentoo-dev 2013-05-23 05:02:52 UTC
(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
Comment 13 SpanKY gentoo-dev 2013-05-23 05:21:24 UTC
(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)
Comment 14 Lars Wendler (Polynomial-C) gentoo-dev 2014-01-15 07:40:07 UTC
*** Bug 494896 has been marked as a duplicate of this bug. ***
Comment 15 Alex Turbov 2014-01-15 12:45:44 UTC
(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)
Comment 16 SpanKY gentoo-dev 2014-01-15 15:17:31 UTC
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
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2014-01-15 23:40:30 UTC
(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.
Comment 18 Steffen Hau 2014-01-20 11:26:38 UTC
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
Comment 19 Alex Turbov 2014-01-21 08:26:46 UTC
(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
Comment 20 Homer 2014-04-14 12:00:05 UTC
(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 '=')
Comment 21 Homer 2014-04-14 12:08:00 UTC
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.
Comment 22 Isaac ‘Will It Work’ Dansicker 2014-06-29 16:45:21 UTC
This also affects sys-libs/db-6.0.30::gentoo as seen in the attachment.
Comment 23 Isaac ‘Will It Work’ Dansicker 2014-06-29 16:47:27 UTC
Created attachment 379930 [details]
Build log

Attempted masked version to see if issue persists in other builds.
Comment 24 Jeroen Roovers (RETIRED) gentoo-dev 2014-07-29 10:42:07 UTC
*** Bug 518056 has been marked as a duplicate of this bug. ***
Comment 25 Marco Ziebell 2014-11-25 18:02:25 UTC
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
Comment 26 Christopher Smith 2014-11-29 03:14:09 UTC
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...
Comment 27 Christopher Smith 2014-11-29 03:15:00 UTC
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.
Comment 28 Jeroen Roovers (RETIRED) gentoo-dev 2014-12-21 09:09:55 UTC
*** Bug 533070 has been marked as a duplicate of this bug. ***
Comment 29 Fabio Scaccabarozzi 2015-01-17 13:33:58 UTC
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.
Comment 31 Andrei Slavoiu 2015-07-28 22:56:47 UTC
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