On Wed, Aug 12, 2020 at 09:33:05AM -0400, Paul Smith wrote:
> As someone who takes a lot of advantage of the flexibility that tools
> like GCC provide I'm wary of reducing that flexibility. On the other
> hand I'm not sure that breaking up the internal structure of GCC's
> installation via symlinks in random ways is something that needs to be
> supported. Anyway, the user can always replace the "lib64" directory
> with a symlink as well.
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.
> 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.
Jakub
