Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-09-05 Thread Christian Bruel

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.
 but
 --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)

Many thanks

Christian



Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-30 Thread Joseph S. Myers
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.
 but
 --with-sysroot looks not appropriate because it changes the search paths
 (that should still be /usr/include on the target tree).

If you are building a cross compiler to a target such as GNU/Linux for 
which the concept of native directory arrangements makes sense, then you 
need --with-sysroot.  That specifies the directory that the final 
installed compiler will use to find headers and libraries (as modified by 
sysroot suffixes and the usual relocation if the compiler is installed 
somewhere other than its configured prefix).

If, when you are building such a compiler, the sysroot is located 
somewhere other than the location specified with --with-sysroot, then you 
need --with-build-sysroot as well.  That's the entire purpose of 
--with-build-sysroot: the case where the build-time location of the 
sysroot for a sysrooted compiler you are building differs from the 
configured location given with --with-sysroot.

I don't see what your use is for a cross compiler without --with-sysroot.  
It's simply not correct for the installed cross compiler to search 
/usr/include, and if you don't specify a sysroot at all then it will just 
search directories such as target/include and target/lib under the 
installation (which cannot represent the complexity of standard GNU/Linux 
directory arrangements; note the absolute paths, intended to be 
interpreted relative to a sysroot, in the libc.so linker script from 
glibc, for example), so that compiler needs a sysroot.

All the above is about cross compilers - compilers with $host != $target.  
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.

-- 
Joseph S. Myers
jos...@codesourcery.com