-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overriding strip-flags in sys-devel/binutils-2.36.1-r1 leads to linker issue when upgrading compiler from GCC10 to GCC11 #739
Comments
build.log mv /usr/lib64/binutils/x86_64-pc-linux-gnu/2.36.1/libibery.a /home and then trying to compile binutils again. My GentooLTO-related changes to /etc/portage/make.conf: CMAKE_MAKEFILE_GENERATOR=ninja I changed TMPDIR to mount it on RAM. |
Just ran into this, above solution worked. |
I also had a similar issue with rebuilding binutils-2.37_p1 after upgrading to GCC11. Thank you for the workaround to move
Emerged with GCC 10 (Thought it was odd that the fatal error message said 9.3)
Emerged with GCC 11 after moving
Instead of overriding strip-flags, I use its included configure option to enable PGO to enable LTO. Figured that'd have someone's interest in testing. /etc/portage/env/binutils.conf
|
Ran into this again with binutils-2.37_p1, why is this happening? |
I ended up quickpkg'ing it from a stage 3 tarball, was a nice experience, no dependencies needed. Maybe it has to do with USE multitarget and libiberty being static? https://gcc.gnu.org/bugzilla//show_bug.cgi?id=41526 A possible workaround? http://download.nust.na/pub3/solaris/sunfreeware/pub/freeware/forsunsites/libiberty.html
Above solution goes against why it's static in the first place. So far, I've found something that may help: https://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries https://hubicka.blogspot.com/2014/04/linktime-optimization-in-gcc-2-firefox.html Although I wasn't able to confirm the above solution worked, or if it could. If someone can test if this works (it didn't for me, but I might as well make an update): In the source libiberty/ directory prior to the compile phase, change AR_FLAGS=rc to rcs in Makefile.in, set $AR to gcc-ar and -ffat-lto-objects to your env. What's certain is adding only -ffat-lto-objects from *FLAGS does not work. Does Some notes: It would be ideal if there was a way to detect $CC and apply llvm-ar or gcc-ar, depending on the compiler used. When the variables for $AR and such aren't set, the binutils versions are used, and they are not good AFAICT.
|
sys-devel/binutils-2.36.1-r1 tries to link against the installed sys-devel/binutils-2.36.1-r1's static library and fails due differing LTO versions.
This error would come up normally when your compiler flags include -flto and you use sys-config/ltoize overrides. And then when you have built sys-devel/binutils-2.36.1-r1 with GCC10 and then upgrade to GCC11 and rebuild sys-devel/binutils-2.36.1-r1 it will lead to this issue. One example of this bug is mentioned here #541.
The issue from my understanding is that sys-config/ltoize should either respect the ebuilds strip-flags (and therefore sys-devel/binutils should be a flag-o-matic.conf exemption) or that sys-devel/binutils has an underlying issue with including the final install path in linker search and therefore linking against libraries there rather than the just built libraries in the temporary install image (noticed this behavior in 2.35.2 as well, so its not new to this version).
Excerpt from the sys-devel/binutils ebuild:
A quick way to reproduce this error relatively safely is to be on a different sys-devel/binutils version and then:
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.36.1/libibery.a
.This will lead to this error:
build.log
The text was updated successfully, but these errors were encountered: