Bug 7790 - bootstrap gcc has bad link directories
Summary: bootstrap gcc has bad link directories
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Pierre Ossman
Keywords: prosaic, wilsj_tester
Depends on:
Blocks: 7841
  Show dependency treegraph
Reported: 2021-11-05 10:56 CET by Pierre Ossman
Modified: 2022-04-01 15:57 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2021-11-05 10:56:17 CET
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.
Comment 1 Pierre Ossman cendio 2022-03-28 07:59:23 CEST
The handling of --build/--host/--target is a bit of a mess with many weird hacks. Let's start by cleaning that up.
Comment 2 Pierre Ossman cendio 2022-03-28 09:12:21 CEST
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.
Comment 10 Pierre Ossman cendio 2022-03-28 14:17:01 CEST
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.
Comment 11 William Sjöblom cendio 2022-04-01 15:57:26 CEST
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!

Note You need to log in before you can comment on or make changes to this bug.