Re: configure --with-sysroot

[<gp at qnx dot com>]

<snip>

Thanks, Daniel.  We have a 'normal' native dir structure, but we use it for
run-time as opposed to build-time.  Even on a native system, we treat all QNX6
targets as cross development.  This simplifies our installs and development
environment, because our target can always find the common system headers in
${sysroot}/usr/include, and binary files in ${sysroot}/${CPU}/*, regardless of
host, and regardless of whether sysroot is null or not.

Still, you are right, it's not a 'real' sysroot.  :-)

I was thinking then of splitting up TARGET_SYSTEM_ROOT and replacing it with
TARGET_HEADER_SYSTEM_ROOT and TARGET_BINARY_SYSTEM_ROOT such that:

  --with-headers-sysroot sets only TARGET_HEADER_SYSTEM_ROOT
  --with-library-sysroot sets only TARGET_BINARY_SYSTEM_ROOT
  --with-sysroot sets them both and takes priority.

Does that sound ok?  Any gotchas I should be aware of? 

Thanks.
GP

> > 
> > 1) Is there a way to prepend (as opposed to append) a search path to gcc's
> > binary/lib search path from within the specs file?  Like "-B" does on the
> > command line?  That way I can get the armle/lib dirs searched first.
> > 
> > 2) If not, would anyone strongly oppose my adding a --with-hdrsysroot and
> > --with-libsysroot (overridden by --with-sysroot) to gcc/configure.in et al?
> 
> The fact is, that's not a sysroot if you have headers in one place and
> libs in another; the whole point of sysroot is to "work exactly like it
> would if we were a native compiler and rooted at $sysroot".  I don't
> recommend working on (1), because if someone requests a library that
> isn't available in armeb/usr/lib you'll go on to search for it in
> usr/lib, and that's bad news.  It may be easier to just avoid using the
> sysroot code for this entirely.
> 
> That said, I guess --with-headers-sysroot isn't terribly gross.  I just
> don't like it very much.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 



--