This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: Cross-compiled GCC 6.1.0 has "../lib" instead of "/usr/lib" in -print-search-dirs output
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Alastair Hughes <hobbitalastair at gmail dot com>, "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 14 Jun 2016 15:01:22 +0000
- Subject: RE: Cross-compiled GCC 6.1.0 has "../lib" instead of "/usr/lib" in -print-search-dirs output
- Authentication-results: sourceware.org; auth=none
- References: <CADx_8+NOnPCJtAp8dXTfkUz_R5SXxP__U4f-SYcu4BK4niK44g at mail dot gmail dot com>
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++.
> 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?
> This issue appears to have been introduced by a change somewhere between
> GCC 5 and GCC 6, as I used to have a working build with GCC 5.
> Unfortunately, I neglected to test more recent builds...
I'm not aware of anything changing in this area but could have missed
something.
> I may well have configured something wrong. I've attached the build log
> and the PKGBUILD, which contains the configure command used.
> Hopefully someone can spot my mistake :)
>
> 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