Bug 938858 – net-dialup/linux-atm-2.5.2-r1: libfl.a is copied from host system

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description dE 2024-09-01 04:30:22 UTC]

My host system has lto while the ROOT system does not. sys-devel/flex has not been build for a long time (it was last build with gcc 13) on my host system. In the ROOT system however, sys-devel/flex has been recently build without LTO support.

While compiling net-dialup/linux-atm for ROOT, the linker is not able to link against libfl.a because 'generated with LTO version 13.0 instead of the expected 14.0' which suggests libfl.a of the host system is being used instead of ROOT for net-dialup/linux-atm which is being built for ROOT. If I copy up libfl.a from the ROOT to the host, net-dialup/linux-atm compiles fine.

Modifying the ebuild to add sys-devel/flex to DEPEND does not help.

While building for ROOT I've the following environment variables set -- 
export ROOT=/upgrade/
export PORTAGE_CONFIGROOT=/upgrade/
export SYSROOT=/upgrade/

Reproducible: Always




for emerge --info see the attachment

[Comment 1 dE 2024-09-01 04:30:57 UTC]

Created attachment 901795 [details]
emerge --info for both ROOT and host.

[Comment 2 dE 2024-09-01 04:31:47 UTC]

Created attachment 901796 [details]
Failed build log for net-dialup/linux-atm-2.5.2-r1

[Comment 3 Sam James 2024-09-01 04:36:43 UTC]

It's not a Portage bug.

It's two issues:
1) flex is a tool for _CBUILD_ because it has to be executed during cross-compilation
2) The general static-libs vs LTO thing (bug 926120)

The package is missing a BDEPEND on flex, but that's the only new bug here. Otherwise, your issue is just bug 926120.

[Comment 4 dE 2024-09-01 04:49:19 UTC]

I'm not concerned about LTO, I'm concerned about the fact that libfl.a on the host is machine specific (-march=native) and if such bytecode is copied from the host machine, it'll result in crashes on the ROOT machine ones it's copied over there (since it's an older machine having a different CPU manufacturer).

Adding flex to BDEPEND did not help.

[Comment 5 Sam James 2024-09-01 04:58:29 UTC]

(In reply to dE from comment #4)
> I'm not concerned about LTO, I'm concerned about the fact that libfl.a on
> the host is machine specific (-march=native) and if such bytecode is copied
> from the host machine, it'll result in crashes on the ROOT machine ones it's
> copied over there (since it's an older machine having a different CPU
> manufacturer).

The reason it fails: LTO bitcode.
The reason it doesn't matter: it's a tool __purely__ for CBUILD, it gets built, executed, results kept, and the tool is thrown away.

[Comment 6 Sam James 2024-09-01 04:59:16 UTC]

that is, nothing linked against libfl will ever be installed.

[Comment 7 dE 2024-09-01 05:09:57 UTC]

Ok. that's great then, thanks.