Re: [GNU] [SuperH] [M32R] limits.h issue

[Ralf Corsepius <ralf_corsepius at rtems dot org>]

On Fri, 2004-12-03 at 10:23 +0900, NIIBE Yutaka wrote:
> On Thu, 2 Dec 2004 14:54:48 -0500 Daniel Jacobowitz <drow@false.org> wrote:
>  > If you're building GNU/Linux targeted compilers, you can use
>  > --with-sysroot instead.  It's much simpler, and this isn't the only
>  > thing it would fix.  Have you tried that?
> 
> Yes, it works, and it works for inhibit_libc too.  It is another way.
> 
> I think that there are two ways.
> 
>     (1) Having target (native) root environment on build host.
> 	For example, it's /sysroot/m32r-linux on i386-linux machine.
> 	Then, file placement is:
> 	    /sysroot/m32r-linux/usr/bin/
> 		target native compiler, linker, assember, and debugger
> 		binaries which run on m32r-linux, recognize m32r-linux
> 
> 	    /sysroot/m32r-linux/usr/include/
> 		include files of target system
> 
> 	    /sysroot/m32r-linux/usr/lib/
> 		libraries of target system
> 
> 	Configure --with-sysroot, to support this scheme.
> 
>     (2) Having target (cross) environment on build host.
> 	For example, it's /usr/m32r-linux on i386-linux machine.
> 	Then, file placement is:
> 	    /usr/m32r-linux/bin/
> 		target cross compiler, linker, assember, and debugger
> 		binaries which run on i386-linux, recognize m32r-linux
> 
> 	    /usr/m32r-linux/include/
> 		include files of target system
> 
> 	    /usr/m32r-linux/lib/
> 		libraries of target system
> 
> 	It seems for me that this is not well supported these days...

IMO there are more sub-cases of (2):

(2.1) The GCC-traditional secondary native compiler building scheme.

External libc; running fixincludes etc. on files in /usr/include etc.
and putting fixincluded headers into GCC internal include dirs.
IIRC, this is what --with-headers originally was addressing.

(2.2) Bootstrapping libc as part of a unified GCC+libc bootrap.

This is the case newlib based targets are facing (Typically bare
targets, Cygwin and RTEMS). In this case, %[target_prefix}/sys-include
is not available nor meaningful (It does not exist).
Instead, headers come from inside of newlib directories, which, when
bootstrapping GCC are part of the build-tree.

> You talk about (1), while I talk about (2).  I know that the
> --with-sysroot works.  However, I think that (2) should be also
> supported in GCC.  Some other systems depend on the file placement of
> (2), and it has been assumed in long time.
> 
> The legacy header copying approach of --with-headers is deprecated.
> But, I'm not sure that it means removal of structure (2).  I believe
> that the structure of (2) is still valid, and will be supported in
> GCC.
I am not sure if deprecating --with-headers is a wise decision.

> Currently, I'm working "cross building bootstrap" for Debian M32R.
> Debian cross comiling environment heavily depends on the structure of
> (2).

Ralf