View previous topic :: View next topic |
Author |
Message |
darkbasic Tux's lil' helper
Joined: 06 Sep 2006 Posts: 133
|
Posted: Fri Dec 18, 2015 10:53 pm Post subject: gcc 5.3 lto problem |
|
|
Hi,
Since compilation failed I had to set
Code: | AR="gcc-ar"
NM="gcc-nm"
RANLIB="gcc-ranlib" |
in /etc/portage/make.conf
Unfortunately there are ebuilds that just ignore the AR exports and still fails.
I read that binutils 2.25 should allow you to use ar/nm/ranlib directly by placing gcc's liblto_plugin.so.0.0.0 in /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins. Unfortunately I have no /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins.
Why?
Also I read I need both dev-libs/cloog and dev-libs/cloog-ppl, but there is no cloog-ppl in portage anymore. Is it really needed? _________________ Computers are like air conditioners:
they stop working properly when you open Windows...
Coltiva Linux, Windows si pianta da solo.
http://www.linuxsystems.it/ |
|
Back to top |
|
|
user Apprentice
Joined: 08 Feb 2004 Posts: 202
|
Posted: Sat Dec 19, 2015 2:20 pm Post subject: |
|
|
this works for me (not for all packages of course)
/etc/portage/make.conf
Code: | ...
CFLAGS="${CFLAGS} -flto=4" # 4 parallel threads for LTO
CFLAGS="${CFLAGS} -fno-fat-lto-objects" # default or not default?
LDFLAGS="${LDFLAGS} -fuse-linker-plugin" # LTO
AR=/usr/local/bin/gcc-ar
NM=/usr/local/bin/gcc-nm
RANLIB=/bin/true
..
|
/usr/local/bin/gcc-ar
Code: | #!/bin/sh
firstarg=${1}
shift
# Sadly, binutils ar doesn't support passing --plugin option before the actual command. Thus, we need to create a wrapper for it
exec /usr/bin/ar "${firstarg}" --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/$(${CC:-/usr/bin/cc} -dumpversion)/liblto_plugin.so "${@}"
|
/usr/local/bin/gcc-nm
Code: | #!/bin/sh
exec /usr/bin/nm --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/$(${CC:-/usr/bin/cc} -dumpversion)/liblto_plugin.so "${@}"
|
ld
Code: | # binutils-config --linker ld.gold
* Setting default linker to ld.gold for x86_64-pc-linux-gnu-2.25.1 ...
# ld -v
GNU gold (Gentoo 2.25.1 p1.1 2.25.1) 1.11
|
|
|
Back to top |
|
|
trippels Tux's lil' helper
Joined: 24 Nov 2010 Posts: 137 Location: Berlin
|
Posted: Sat Dec 19, 2015 2:21 pm Post subject: |
|
|
Well, just create the directory and add a symlink.
Code: |
% ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0
lrwxrwxrwx 1 root root 65 Dec 19 11:38 /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0 -> /usr/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/liblto_plugin.so.0.0.0
|
|
|
Back to top |
|
|
darkbasic Tux's lil' helper
Joined: 06 Sep 2006 Posts: 133
|
Posted: Mon Dec 21, 2015 7:39 pm Post subject: |
|
|
trippels wrote: | Well, just create the directory and add a symlink.
Code: |
% ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0
lrwxrwxrwx 1 root root 65 Dec 19 11:38 /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0 -> /usr/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/liblto_plugin.so.0.0.0
|
|
It seems to work, but why do I get "plugin needed to handle lto object" while compiling virtualbox ~amd64? _________________ Computers are like air conditioners:
they stop working properly when you open Windows...
Coltiva Linux, Windows si pianta da solo.
http://www.linuxsystems.it/ |
|
Back to top |
|
|
darkbasic Tux's lil' helper
Joined: 06 Sep 2006 Posts: 133
|
Posted: Fri Dec 25, 2015 12:00 pm Post subject: |
|
|
I can't manage to get it working...
I have installed dev-libs/cloog and I have USE="graphite lto..." in /etc/portage/make.conf
GRAPHITE="-floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block"
CFLAGS="-march=native -O2 -pipe -flto=8 ${GRAPHITE} -ftree-vectorize"
CXXFLAGS="${CFLAGS}"
LDFLAGS="${CFLAGS} -fuse-linker-plugin"
I symlinked /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so.0.0.0 to /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0 (creating the directory) and I removed
AR="gcc-ar"
NM=gcc-nm
RANLIB=gcc-ranlib
from /etc/portage/make.conf.
I also switched to the gold linker:
binutils-config --linker ld.gold
and I made gold default when reinstalling binutils:
echo 'EXTRA_ECONF="--enable-gold=default"' >> /etc/portage/env/gold.conf
echo "sys-devel/binutils gold.conf" >> /etc/portage/package.env
I can build the vast majority of the packages but I still have *LOTS* of failures.
/etc/portage/env/no-lto.conf
Code: | CFLAGS="${CFLAGS} -fno-lto -fno-use-linker-plugin"
CXXFLAGS="${CXXFLAGS} -fno-lto -fno-use-linker-plugin"
LDFLAGS="${LDFLAGS} -fno-lto -fno-use-linker-plugin" |
/etc/portage/env/no-graphite.conf:
Code: | CFLAGS="${CFLAGS} -fno-loop-interchange -fno-tree-loop-distribution -fno-loop-strip-mine -fno-loop-block"
CXXFLAGS="${CXXFLAGS} -fno-loop-interchange -fno-tree-loop-distribution -fno-loop-strip-mine -fno-loop-block"
LDFLAGS="${LDFLAGS} -fno-loop-interchange -fno-tree-loop-distribution -fno-loop-strip-mine -fno-loop-block" |
Even if I put "app-text/calibre no-lto.conf no-graphite.conf" in /etc/portage/package.env and if I switch back the linker to ld.bfd (binutils-config --linker ld.bfd) I still get failures. Before enabling LTO and GRAPHITE I rebuilt world with gcc-5.3 and I had only 3 failures.
What's the problem?
Example of failure (calibre):
Code: | fontconfig_database.o:(.data.rel.ro._ZTV19QFontconfigDatabase[_ZTV19QFontconfigDatabase]+0x58): undefined reference to `QBasicFontDatabase::releaseHandle(void*)'
collect2: error: ld returned 1 exit status
Makefile:95: recipe for target '/var/tmp/portage/app-text/calibre-2.47.0/work/calibre-2.47.0/src/calibre/plugins/libheadless.so' failed
make: *** [/var/tmp/portage/app-text/calibre-2.47.0/work/calibre-2.47.0/src/calibre/plugins/libheadless.so] Error 1 |
_________________ Computers are like air conditioners:
they stop working properly when you open Windows...
Coltiva Linux, Windows si pianta da solo.
http://www.linuxsystems.it/ |
|
Back to top |
|
|
darkbasic Tux's lil' helper
Joined: 06 Sep 2006 Posts: 133
|
Posted: Tue Jan 05, 2016 4:43 pm Post subject: |
|
|
Any idea? _________________ Computers are like air conditioners:
they stop working properly when you open Windows...
Coltiva Linux, Windows si pianta da solo.
http://www.linuxsystems.it/ |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 402
|
Posted: Fri Mar 18, 2016 7:33 pm Post subject: |
|
|
I don't know if what I'm doing is 100% correct but, with gcc-5.3.0, it seems that wrapper-plugins are no longer required.
Just to have /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0
But there is a catch that I don't understand, therefore my first affirmation regarding correctnes: "auto-plugins" don't work with -fno-fat-lto-objects witch is on by default. I don't know if is gcc itselft or binutils. A lot of missing simbols or warning that plugin is required from x86_64-pc-linux-gnu-strip.
Using gcc-5.3.0 with lto and -ffat-lto-objects I get my system usable. Of course, there are still packages that not support lto, around 20.
By the way: for perl: https://rt.perl.org/Public/Bug/Display.html?id=125096 _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
Petross404 n00b
Joined: 27 Sep 2016 Posts: 55
|
Posted: Fri May 12, 2017 1:33 pm Post subject: |
|
|
darkbasic wrote: |
I symlinked /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so.0.0.0 to /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0 (creating the directory) and I removed
AR="gcc-ar"
NM=gcc-nm
RANLIB=gcc-ranlib
from /etc/portage/make.conf.
|
Note: You could symlink the plugin at /usr/lib/bfd-plugins too. I think this is the default location.
Now, is removing ar,nm etc necessary when symlink the plugin? Also can someone ignore the plugin and use only ar,nm,ranlib to use LTO?
I am using them both :
Code: | AR="/usr/local/bin/gcc-ar"
NM="/usr/local/bin/gcc-nm"
RANLIB=/usr/local/bin/gcc-ranlib
#AR="/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0/gcc-ar"
#NM="/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0/gcc-nm"
#RANLIB="/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0/gcc-ranlib"
MAKEOPTS="-j3 -l2"
LTO="-flto=3 -flto-report -fuse-linker-plugin"
CFLAGS="${LTO} ...."
....
LDFLAGS="-Wl,-O1 ${LTO}" |
Code: | $cat /usr/local/bin/gcc-ar
#!/bin/sh
firstarg=${1}
shift
# Sadly, binutils ar doesn't support passing --plugin option before the actual command. Thus, we need to create a wrapper for it
exec /usr/bin/ar "${firstarg}" --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/$(${CC:-/usr/bin/cc} -dumpversion)/liblto_plugin.so "${@}" |
Code: | $ cat /usr/local/bin/gcc-nm
#!/bin/sh
exec /usr/bin/nm --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/$(${CC:-/usr/bin/cc} -dumpversion)/liblto_plugin.so "${@}" |
Code: | $ cat /usr/local/bin/gcc-ranlib
#!/bin/sh
firstarg=${1}
shift
exec /usr/bin/ranlib "${firstarg}" --plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/$(${CC:-/usr/bin/cc} -dumpversion)/liblto_plugin.so "${@}" |
I got the idea for the scripts : http://hubicka.blogspot.gr/2014/09/linktime-optimization-in-gcc-part-3.html |
|
Back to top |
|
|
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Mon Jun 12, 2017 4:59 pm Post subject: |
|
|
costel78 wrote: | I don't know if what I'm doing is 100% correct but, with gcc-5.3.0, it seems that wrapper-plugins are no longer required.
Just to have /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0
But there is a catch that I don't understand, therefore my first affirmation regarding correctnes: "auto-plugins" don't work with -fno-fat-lto-objects witch is on by default. I don't know if is gcc itselft or binutils. A lot of missing simbols or warning that plugin is required from x86_64-pc-linux-gnu-strip.
Using gcc-5.3.0 with lto and -ffat-lto-objects I get my system usable. Of course, there are still packages that not support lto, around 20.
By the way: for perl: https://rt.perl.org/Public/Bug/Display.html?id=125096 |
++ _________________ My blog |
|
Back to top |
|
|
Petross404 n00b
Joined: 27 Sep 2016 Posts: 55
|
Posted: Sun Nov 05, 2017 7:41 pm Post subject: |
|
|
So what "plugin needed to handle lto object" messages mean after all? |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 402
|
Posted: Sun Nov 05, 2017 8:08 pm Post subject: |
|
|
It is a binutils bug #603594.
Affecting only static libraries. On a normal setup they are built but not installed. _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
Petross404 n00b
Joined: 27 Sep 2016 Posts: 55
|
Posted: Sun Nov 05, 2017 8:27 pm Post subject: |
|
|
Thank you. For a long time I feared this message meant that my toolchain wasn't lto-capable because of some mistake of mine. |
|
Back to top |
|
|
|