Gentoolto: dev-lang/python-3.8.0 fails to build with LTO

[ElDavoo]

See https://bugs.gentoo.org/700012 , explains much better than I do.
Removing -flto fixes the issue for me.

[ElDavoo]

It also looks like fat objects can fix the issue too.

[elsandosgrande]

I can confirm that adding the fat allows it to compile again.

[pchome]

@elsandosgrande

I can confirm that adding the fat allows it to compile again.

    IN CASE OF
        LTO
-------------------
        USE
 -ffat-lto-objects

TL;DR: use ax_cv_c_float_words_bigendian=no on "regular" PC system.

Problem source: https://www.gnu.org/software/autoconf-archive/ax_c_float_words_bigendian.html

@InBetweenNames, to solve many of this autotools problems (including "variable substitution" problem) it maybe worth to create the collection of such problematic tests and generate make.conf.lto.autoconf, which will contain _cv_ variables.
I guess it can be separate project w/ stripped -flto in ebuild, or configure.in as part of sys-config/ltoize. Not so perfect solution, but should fix many of current and future problems (and shrink the ltoworkarounds.conf a bit, I guess).

[InBetweenNames]

@pchome Agreed -- I have had similar thoughts too. Most of our problems at this point are the configure scripts not playing well with LTO. I only wish I had more time to tackle it!

[InBetweenNames]

Was able to bypass this by setting it manually as the config stated.

[InBetweenNames]

Sigh. Yet another autoconf macro that depends on compiler internals. So essentially, the test string in the macro isn't present in LTO object file output, so it is unable to determine the endianness of floats in the system that are larger than one word.

For convenience, we can build with fat lto objects -- the result should be identical. For users that want to really be sure only LTO is being used, edit configure manually with the correct value. It is most likely no:

~~~
14250c14250

< ax_cv_c_float_words_bigendian=unknown

ax_cv_c_float_words_bigendian=no
~~~

I would include a patch to do this, but I am aware that some users may be running GentooLTO on systems where the answer would be yes and I don't want to cause problems for those users.

You can include this patch in your /etc/portage/patches/ if needed.

[jiblime]

That's odd; define ax_cv_c_float_words_bigendian wasn't working before for me, but it is now.

Predefining even by detecting the host system's endianness would not be a good idea in case of cross-compilation. Is there a way to pass fat objects to only the tests required?

[perfect7gentleman]

dev-lang/python-3.8.1::pg_overlay was built with the following:
USE="gdbm ncurses readline sqlite ssl xml -bluetooth -build -examples -hardened -ipv6 -libressl -test -tk -wininst"
CFLAGS="-march=native -mtune=native -O3 -pipe -flto=7 -fuse-linker-plugin -fomit-frame-pointer -fno-plt -fno-stack-protector -s -fwrapv"
CXXFLAGS="-march=native -mtune=native -O3 -pipe -flto=7 -fuse-linker-plugin -fomit-frame-pointer -fno-plt -fno-stack-protector -s -fwrapv"
FEATURES="preserve-libs usersandbox merge-sync ipc-sandbox unmerge-logs ebuild-locks distlocks binpkg-docompress multilib-strict xattr config-protect-if-modified news parallel-fetch sandbox usersync binpkg-dostrip unknown-features-warn strict unmerge-orphans assume-digests protect-owned pid-sandbox binpkg-logs fixlafiles network-sandbox parallel-install userpriv userfetch sfperms"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--strip-debug -flto=7 -fuse-linker-plugin -L."

[InBetweenNames]

Looks like this was fixed upstream in Gentoo by adding -ffat-lto-flags if -flto is in your CFLAGS. This makes the most sense for now, as the fat LTO objects will get optimized out of the final binaries anyway (Python builds perfectly fine with LTO). The non-LTO symbols should be completely ignored during linking. Annoying that this had to be resorted to, but at least it's settled. No performance impact should be observable from using -ffat-lto-objects for this package.

[perfect7gentleman]

add to ebuild
export ax_cv_c_float_words_bigendian=no
and it can be built with -flto and without -ffat-lto-flags