Re: configure --with-sysroot

[<gp at qnx dot com>]

Alexandre Oliva <aoliva at redhat dot com> said:

<snip discussion on spec'ing sysroot>

> 
> What I don't quite like about this approach is:
> 
> - it breaks ld and gdb sysroot support again and, since they don't
>   have specs, this will be trickier to fix.  This just means that they
>   won't be able to find stuff outside the primary sysroot (if there is
>   one), but it may still be inconvenient, and may require flags such
>   as -rpath-link %R/usr/lib to be passed to the linker from GCC specs,
>   which sysroot support in the linker had obviated.
> 
> - GCC doesn't support very well the notion of multiple standard header
>   directories.  e.g., it will only run fixincludes in one directory,
>   that must be in place before fixincludes run, which pretty much
>   requires the existence of one `default' sysroot tree, whose fixed
>   headers are going to make it to the GCC internal headers directory,
>   which may cause you problems when you use a different headers tree,
>   unless you multi-sys-root that as well.  It feels more and more like
>   we don't really want multiple headers, but rather a single shared
>   headers directory, even when using multiple binary sysroots, which
>   may also get tricky in case the headers are not say multi-endian- or
>   multi-ABI-compatible.
> 
> Thoughts?

Your second point sounds exactly like our install.  We have a single shared
headers directory that is multi-endian and multi-ABI, with multiple binary
sysroots.  This is what I am trying to find a way to get working in gcc.  So
we have come full circle.  What now?

QNX's concept of sysroot targets one OS, and all CPU and endian variants
supported by that version of the OS.  To use my arm-nto example, I am trying
to get a single gcc binary that will work with:

  ${QNX_SYSROOT}/usr/include
  ${QNX_SYSROOT}/armle/lib
  ${QNX_SYSROOT}/armle/usr/lib
  ${QNX_SYSROOT}/armbe/lib
  ${QNX_SYSROOT}/armbe/usr/lib

or

  ${QNX_SYSROOT}/usr/include
  ${QNX_SYSROOT}/x86/lib
  ${QNX_SYSROOT}/x86/usr/lib

This will require a default sysroot, as you say, and a way to spec the
binary_sysroots.  If things are designed to work like this, it should not then
matter if the default sysroot and multilib'd sysroots are the same or different.

Thoughts?  Comments?  Ideas?   At this point I am not sure how to proceed.

:-)

In the past I had hard-coded sysroot paths in the specs, thus locking our
build of gcc to a particular install path.  This was _gross_, and I want to do
things right this time, particularly since I am hoping to get my changes
rolled into the FSF source tree.

Please LMK.

Cheers.
GP

> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
> CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
> Free Software Evangelist                Professional serial bug killer
> 



--