On 6/17/16, Matthew Fortune <Matthew.Fortune@xxxxxxxxxx> wrote: > Alastair Hughes <hobbitalastair@xxxxxxxxx> writes: >> On 6/15/16, Matthew Fortune <Matthew.Fortune@xxxxxxxxxx> wrote: >> > Alastair Hughes <hobbitalastair@xxxxxxxxx> 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
