This is the mail archive of the
mailing list for the GCC project.
Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation
- From: Christian Bruel <christian dot bruel at st dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Sep 2013 09:53:06 +0200
- Subject: Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation
- Authentication-results: sourceware.org; auth=none
- References: <52209AA8 dot 1080607 at st dot com> <52209CAD dot 9060402 at st dot com> <Pine dot LNX dot 4 dot 64 dot 1308301538050 dot 17271 at digraph dot polyomino dot org dot uk>
On 08/30/2013 05:50 PM, Joseph S. Myers wrote:
> On Fri, 30 Aug 2013, Christian Bruel wrote:
>> So to cross build a target library |
>> --with-build-sysroot=|dir looks appropriate to specify the alternative
>> host root path.
>> --with-sysroot looks not appropriate because it changes the search paths
>> (that should still be /usr/include on the target tree).
> Your patch suggests you are actually using a cross compiler to build a
> native compiler - $build != $host == $target. In that case, it's best not
> to build target libraries at all, as they will already have been built
> with the $build-x-$target cross compiler that must have previously been
> built from the same GCC sources, with the same configuration. That is,
> "make all-host" and "make install-host", and copy the libraries from the
> previous build. And since you already have such a $build-x-$target
> compiler, it would seem best to determine what directory that compiler
> actually searches for headers and compute target_header_dir that way, to
> the extent that the target headers need examining to determine
> configuration of the compiler proper.
Thanks for the hint. Indeed in the normal case it doesn't make sense to
rebuild twice the target libraries, the target build is simplified with
the all-host rules and reusing those built with the cross-gcc is best.
But there are cases were it is still interesting to rebuild them (e.g
the target gcc is not from the same version or have different
CFLAGS_FOR_TARGET, or for cross-checking reasons). Let me ping the
patch (from http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01748.html)