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

[Alastair Hughes]

On 6/17/16, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
> 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

Solved, thanks :)
Alastair Hughes