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
