Re: configure --with-sysroot

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar  6, 2003, <gp at qnx dot com> wrote:

> I'd love to spec/multilib the sysroot _and_ allow the header_sysroot to be
> separately specified at configure and/or via specs.

Well, header_sysroot feels like a step backward to me, like going back
to --with-headers.  Maybe you could just use that, instead of
inventing yet another configure option?  I realize --with-headers
copies the tree into ${target_alias}/sys-include, instead of just
using what's in place, but it seems better suited to your purpose of
having a single header tree shared by multiple sys-roots.  It very
likely doesn't work along with --with-sysroot ATM, but it shouldn't be
too hard to fix.  Maybe introduce --with-installed-headers, that
doesn't do the copying?

> Regardless of whether this looks ok or not, any pointers on how one
> would go about implementing spec'ed sysroot/header_sysroot?

As a first try, I'd run target_system_root through specs just before
trying to relocate it.  Alternately, you might tweak the %R expander
so as to append some standard spec, say SYSROOT_SUBDIR_SPEC, if it's
defined, to target_system_root.  All this in gcc.c.

It might take some additional tweaking to pass the header search
prefix to the preprocessor, but hey!, you don't *want* to do that.
But I see that, in most cases, we will want to do it, so a patch that
implements this had better support per-sys-root header directories as
well.  Perhaps use different specs for header sysroot and library
sysroot, say SYSROOT_HEADERS_SUBDIR_SPEC and SYSROOT_SUBDIR_SPEC, with
the former defaulting to the latter, and the latter defaulting to the
empty string, would do.  If SYSROOT_HEADERS_SUBDIR_SPEC is non-empty,
you'd pass -isysroot to the preprocessor, so that it would find the
headers in the right place.

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?

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