RE: Cross-compiled GCC 6.1.0 has "../lib" instead of "/usr/lib" in -print-search-dirs output

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Alastair Hughes <hobbitalastair@gmail.com> writes:
> On 6/15/16, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
> > Alastair Hughes <hobbitalastair@gmail.com> writes:
> >> I've cross compiled GCC 6.1.0 (target/build is mips, host is x86_64).
> >
> > This description does not match the log. The log is for: build=x86_64
> > host/target=mips. The log shows the build system using a pre-installed
> > x86_64->mips cross compiler when building libgcc/libstdc++.
> 
> My bad, I mixed that up...
> 
> >> The resulting compiler will not run as it cannot find cc1, because the
> >> search dirs are incorrect; they are prefixed with "../lib" instead of
> >> "/usr/lib" (eg instead of /usr/lib/gcc/mips-linux-musl/6.1.0/ ..., the
> >> path is ../lib/gcc/mips-linux-musl/6.1.0/ ...).
> >
> > Can you show the full search paths that GCC tries?
> 
> install: ../lib/gcc/mips-linux-musl/6.1.0/
> programs: =../lib/gcc/mips-linux-musl/6.1.0/:../lib/gcc/:../mips-linux-musl/bin/mips-
> linux-musl/6.1.0/:../mips-linux-musl/bin/
> libraries: =../lib/gcc/mips-linux-musl/6.1.0/:../lib/gcc/:../mips-linux-musl/lib/mips-
> linux-musl/6.1.0/:../mips-linux-musl/lib/:../lib/mips-linux-musl/6.1.0/:../lib/:/lib/mips-
> linux-musl/6.1.0/:/lib/:/usr/lib/mips-linux-musl/6.1.0/:/usr/lib/
> 
> >> If the problem is not a configuration mistake, where would I look to
> >> find out what could be the issue? Where does the GCC build process
> >> determine/set what the search dirs should be?
> >
> > The search paths are constructed out of the prefix in this case as well
> > as having a relative path as a fallback.
> >
> > The absolute path that you build GCC with (--prefix) will be searched
> > first with lib/gcc/xyz suffixed otherwise the directory containing the
> > GCC executable will be searched by suffixing ../ to get to the root of
> > the toolchain and then lib/gcc/xyz.
> >
> > The latter form of searching only works if you invoke the 'main' GCC
> > executable in <root>/bin/[mips-linux-musl-]gcc if you invoke the copy
> > at <root>/mips-linux-musl/bin/gcc then the relative path will fail as
> > that copy of gcc is 2 levels deep not 1 level.
> >
> > Hope that helps a bit,
> > Matthew
> 
> Thanks Matthew!
> 
> I continued looking based on your explanation and discovered that the
> issue appears to stem from running gcc with no PATH set (I was booting
> directly into a shell script to simplify debugging). Without
> investigating too deeply into gcc, it appears that gcc searches
> through PATH to find itself; as PATH is unset, it cannot locate
> itself.
> 
> I can reproduce in my development environment by running
>   unset $PATH; bash -c "gcc -print-search-dirs"

These kind of unusual use-cases/issues are not generally given much
attention as I think the fixes would quickly snowball and make the
driver code even more hideously complex than it is today. Similar
kind of issues occur when TMP/TMPDIR/TEMP are undefined and a temp
file is needed.

> It seems that gcc is not searching --prefix (set to /usr in this
> case); is that the intended behavior?

I thought that the fallback to the original prefix was done for all
types of search path. I can see it for libraries and I believe it happens
for includes but don't know why it doesn't get used for programs (or
if it is supposed to). I don't have time to trawl gcc.c to figure out
right now but someone else may know.

Are you up and running with the PATH issue resolved at least?

Matthew