Bug 494228 – sys-devel/binutils: supporting multiple/versioned linker plugins (e.g. SLOT-ed gcc)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description David Kredba 2013-12-14 11:46:17 UTC]

I would like to have general LTO support after gcc-4.9.0 will be released in Gentoo.

I reported two LTO gcc-4.9.0 alpha related bugs to their package owners and was rejected. So I reported my issue at GCC Bugzilla and got this information from
Markus Trippelsdorf:

Gcc now uses slim-LTO-objects by default. Therefore you need to run binutils (ar, nm, ranlib) that use the linker plugin.
You can use gcc-ar, etc. for this purpose.

He posted a patch (is attached by him to GCC bug report 59505) to binutils and it was ignored.

Could you kindly please see how is he using it and if it can be enabled in Gentoo? Maybe by a new FEATURE "lto" that will export AR, AS, RANLIB and NM to its gcc variant?

For me AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib worked well when tried it on before problematic packages (mesa-10.0.1 and openldap-2.4.38-r1). I will test it on Seamonkey and Firefox now.

Thank you in advance.

Reproducible: Always

[Comment 1 Michał Górny 2013-12-16 16:47:03 UTC]

Can the issue be solved through adding gcc's plugin to bfd-plugins alike outlined for clang in bug #462554? If yes, does it affect non-LTO builds?

Then, can you check whether adding clang's LTO plugin interferes with gcc's LTO? Can we have both plugins together there?

I'm thinking that the most friendly way of handling the clang side would be to create a separate package (PDEPEND) that would symlink the plugin to the appropriate binutils directories.

[Comment 2 SpanKY 2013-12-16 18:42:56 UTC]

(In reply to Michał Górny from comment #1)

i don't think a symlink alone would help.  all `gcc-ar` and such do is run ar with the option --plugin /usr/libexec/gcc/$CHOST/$GCC_VER/liblto_plugin.so.

the upstream gcc bug includes a patch that changes the default --target to "plugin".  not entirely sure what that accomplishes, but fairly certain that it alone wouldn't help either.

we can't drop every gcc liblto_plugin.so into the bfd-plugins/ dir as it is a version-specific plugin.  we can't let gcc-config manage it as people are allowed to run `gcc-$VER` at any time.

[Comment 3 Ryan Hill (RETIRED) 2014-02-27 08:47:56 UTC]

This is being discussed upstream.  I'll see if I can dig up a link.

[Comment 4 Ryan Hill (RETIRED) 2014-02-28 06:40:41 UTC]

http://gcc.gnu.org/ml/gcc/2014-02/msg00128.html

[Comment 5 David Kredba 2014-04-20 16:47:23 UTC]

Support for gcc lto symbol plugin autoloading is in binutils already.

[Comment 6 Ryan Hill (RETIRED) 2014-04-21 01:24:47 UTC]

It is now.  We still need a way to handle installing multiple versions choosing the right one.

[Comment 7 Ryan Hill (RETIRED) 2014-04-23 01:10:26 UTC]

*** Bug 502952 has been marked as a duplicate of this bug. ***

[Comment 8 SpanKY 2015-03-31 06:16:29 UTC]

*** Bug 544654 has been marked as a duplicate of this bug. ***

[Comment 9 SpanKY 2015-09-24 19:19:59 UTC]

*** Bug 522316 has been marked as a duplicate of this bug. ***

[Comment 10 SpanKY 2015-09-24 19:20:32 UTC]

*** Bug 462796 has been marked as a duplicate of this bug. ***

[Comment 11 David Kredba 2017-12-18 19:49:29 UTC]

I think that this case can be closed after bug #630066 was resolved.
Can I please?

[Comment 12 Andreas K. Hüttel 2017-12-19 19:53:56 UTC]

(In reply to David Kredba from comment #11)
> I think that this case can be closed after bug #630066 was resolved.
> Can I please?

Already done ;)