[lfs-dev] Multilib patch

Thomas Trepl thomas at linuxfromscratch.org
Sun Jan 6 01:16:41 PST 2019

Am Sonntag, den 06.01.2019, 14:16 +0800 schrieb Kevin Buckley via lfs-
> A web search for my GCC-internal zlib config error
> configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
> turned up, amongst others, these two, the first of which results from
> an LFS build !
> https://stackoverflow.com/questions/46487529/crosscompiling-gcc-link-tests-are-not-allowed-after-gcc-no-executables-when-che
> https://github.com/easybuilders/easybuild-easyconfigs/issues/3964
> The second of those suggests that it may be the lack of a "multilib capable"
> toolchain ON THE HOST that is the issue for me?
No, i've just tested building it from an LFS-8.2 without ML. That is
what chapter 5 is for - make us (more or less) independent from host.

> With that in mind, I'm coming back to my original remarks about rebuidling
> in that:
> the way I last "upgraded" an x86_64 LFS to have multilib capibilty was by
> following one of DJ's old books, wherein things were effectively done in
> these stages:
> x86_64 host -> x86_64 LFS-tools
> x86_64 LFS-tools -> x86_64 LFS
> x86_64 LFS -> Multilib LFS-tools components
> Multilib LFS-tools -> Multilib LFS components
> Indeed, after the Binutills pass1 now, the only file in /tools/bin are
> x86_64-lfs-linux-gnu-addr2line  x86_64-lfs-linux-gnu-nm
> x86_64-lfs-linux-gnu-ar         x86_64-lfs-linux-gnu-objcopy
> x86_64-lfs-linux-gnu-as         x86_64-lfs-linux-gnu-objdump
> x86_64-lfs-linux-gnu-c++filt    x86_64-lfs-linux-gnu-ranlib
> x86_64-lfs-linux-gnu-elfedit    x86_64-lfs-linux-gnu-readelf
> x86_64-lfs-linux-gnu-gprof      x86_64-lfs-linux-gnu-size
> x86_64-lfs-linux-gnu-ld         x86_64-lfs-linux-gnu-strings
> x86_64-lfs-linux-gnu-ld.bfd     x86_64-lfs-linux-gnu-strip
> suggesting that any non-x86_64 stuff has to come from the host ?
There is not much to see in ch5-binutils-pass1.

> Then again, you've stated that your sucessful build came from an
> non-multilib host.
Yes, see above.

> FYI, my host (Ubuntu 1404 - yes. old, yes) has
> Binutils: (GNU Binutils for Ubuntu) 2.24
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
> (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19
> so is a little diferent to what the Multilib book suggests things
> have been tested against, bis:
> Binutils-2.25 (Versions greater than 2.31.1 are not recommended as
> they have not been tested)
> GCC-4.9 including the C++ compiler, g++ (Versions greater than 8.2.0
> are not recommended as they have not been tested)
> Glibc-2.11 (Versions greater than 2.28 are not recommended as they
> have not been tested)
Hmmmm, usually we do not dig around in issues with hosts doesn't match
the requirements. Anyway, the "oldest" thing i have around is a
CentOS7. Tried to build there, but failed with quite simmilar messages
at ch5-gcc-pass1.

> I think I may find the best way forwards to be one in which I build an
> non-Multilib LFS 8-3
> and then use that to boostrap the Multilib one, as that would give me
> a "host" with
> Binutils-2.31.1
> GCC-8.2.0
> Glibc-2.28

Thats what I'd suggest - then we have a well defined environment. Make
sure that the running kernel is 32-bit-enabled

[*] 64-bit kernel
    Executable file formats / Emulations  --->
        [*] IA32 Emulation
        [*] x32 ABI for 64-bit mode

> Just out of interest then, what are the Binutils, GCC, Glibc versions on
> the "non-multilib" host that your Multilib buils suceeds ?
The only non-ML (but kernel is 32bit-enabled) i have around is a LFS-
8.1+ machine which is actually from 2018/01/01. gcc is 7.2.0, glibc is
2.26, binutils-2.29.1.  There the built ran smoothly.


More information about the lfs-dev mailing list