On Wed, 2020-08-12 at 15:37 +0200, Jakub Jelinek wrote: > The important thing is that GCC wants to be relocatable, so most > paths are not hardcoded into the compiler, but depend on where the > gcc driver actually is. One can then just move the whole gcc tree > somewhere else and it should still work.
For sure! I take full advantage of this: as mentioned I check GCC into Git and users are free to clone that repo into whatever directory they want, anywhere on their filesystem, and it works. If we consider the internal paths GCC computes to be constructed in two parts: <relocatable-prefix>/<internal-suffix> then the part that I'm talking about is the <internal-suffix>. > > It appears that what happens is that the frontend computes the path > > to the "lib" (32bit) directory, then when it wants to look for > > 64bit libraries instead of re-computing the path from scratch with > > "lib64", it just adds on a "../lib64" to the 32bit path. > > That is because that is the way OS multilib directories are > specified, it is defined by adding `gcc -print-multi-os-directory > $CFLAGS` to the normal paths. Well, perhaps the right thing to do is simplify the results of this without requiring that the original exists.
