During bootstrapping of cenbuild we have a special version of gcc in the package cendio-build-gcc-bootstrap. This gcc is a cross compiler from the native system (e.g. Fedora or RHEL) to the cenbuild environment. I.e. it should execute using the system libraries, but should link output programs to the cenbuild libraries. In order to run this special gcc we also need some extra libraries that we don't want to assume exist on the system. We put these extra libraries in a special bootstrap directory and link our special gcc to these libraries. Unfortunately the paths this gcc uses to find libraries for output binaries are not set up correctly. It also looks in that extra bootstrap directory for libraries. This is incorrect since those libraries are built to execute on the primary system, not inside cenbuild. Right now we hack around this by setting $LIBRARY_PATH, forcing gcc to look in the cenbuild environment first. This works fine in most cases, but not in all. The case where it breaks is for things that need to build helper programs as part of the build. I.e. they need to use both the host gcc and the target gcc. Since we set $LIBRARY_PATH we override the search paths for both of these gcc, not just for the target gcc. An example of such a package is perl, which first builds a native miniperl to help it compile the final perl.
The handling of --build/--host/--target is a bit of a mess with many weird hacks. Let's start by cleaning that up.
That seems to have solved it. Everything now builds fine, and if I compare the output of "gcc -print-search-dirs" I can see that the problematic line has been removed: > /opt/cendio-build/arch/x86_64/usr/bootstrap/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../../lib64/ (this would resolve to /opt/cendio-build/arch/x86_64/usr/bootstrap/lib64/) We also still have the proper directory for compiler target libraries (e.g. libstdc++): > /opt/cendio-build/arch/x86_64/usr/bootstrap/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/ And it is listed before the chroot paths: > /opt/cendio-build/arch/x86_64/lib/../lib64/ > /opt/cendio-build/arch/x86_64/usr/lib/../lib64/ So everything now looks okay.
Everything now committed and working. I did a build of ThinLinc (both client and server) and briefly tested the server on Ubuntu 20.04. Everything worked fine. Also reran the test program for bug 7789 to make sure perl still works without the previous ugly hack.
I have tested the following: • Smoke testing of compiler infrastructure for all cenbuild architectures (gcc, glibc, binutils, mpc, mpfr, and texinfo are all used either when bootstrapping the compilers or when using the bootstrapped compiler) • `<target>-gcc' produce valid binaries for the <target> architecture • `<host>-gcc' produce valid binaries for the <host> architecture • tlstunnel for tlwebaccess and tlwebadm seemingly works as expected (indirect user of `gmp') • Smoke testing of all other tools for all their cenbuild architectures that were touched by the changes in this bug. • And finally, the build system bootstraps without any issues. Additionally, I have gone through all the changes, all of which are looking good. These changes have been a massive improvement in terms of de-magicifying the previously rather convoluted compiler infrastructure sequence. Nice! Closing!
