Re: configure --with-sysroot

[<gp at qnx dot com>]

BTW, I am going to start on the SYSROOT_SUBDIR_SPEC and 
SYSROOT_HEADERS_SUBDIR_SPEC ideas while we think on the rest of it.

Thanks for your help.  Let you know.

Cheers.
GP

gp at qnx dot com said:

> 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
> > 
> 
> 
> 
> -- 
> 
> 
> 
> 



--