This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: introduce configure --with-sysroot


On Thu, Aug 22, 2002 at 10:21:15PM -0300, Alexandre Oliva wrote:
> Traditionally, cross compilers have been configured using the flags
> --with-headers and --with-libs.  This poses a number of problems to
> the creation of cross compilers to hosted architectures, particularly
> ones with multilibs, because then all the libs, start and endfiles
> have to be placed in a single directory, which may not work very well,
> or at least make it slightly trickier to get right than mirroring the
> exact structure of the target system's tree.
> 
> This patch introduces --with-sysroot=<tree>, intended to deprecate
> --with-headers and --with-libs, that tells GCC to copy the specified
> <tree> into its install tree and use that as the root of the target
> system.

I second H-P's comment about --with-installed-sysroot.

> It also introduces %R as a spec, that can be used to prefix absolute
> pathnames such that, when a cross compiler to a hosted system is
> created, GCC can find files in the target system root tree, instead of
> in the host system's tree.  This may simplify a number of weirdnesses
> in targets that can be used as cross compilers.  In general, however,
> no changes are necessary.

I love it - I hadn't thought of this approach at all.  Now, what would
be really useful would be if I could specify where the sysroot would be
copied (relative path to the install root) instead of necessarily
"sys-root".  But that's easy enough as a local patch.  We have existing
installations which constrain us to calling this directory "target".

> The only recommended change, for GNU/Linux targets, is to pass the
> correct --rpath-link flag to GNU ld, so that it, when something is
> linked with a shared library that has dependencies, it knows where to
> look for such dependencies.  This could presumably be fixed with some
> changes in GNU ld so as to use sysroot too, but I'm not convinced it's
> worth the trouble.  The beauty of the sysroot approach is that, when
> building a native compiler, %R will expand to nothing, and everything
> will just work.

I've got the necessary patches to GNU ld to do this.  I can clean them
up and submit them if you want.  They're useful occasionally when
people invoke LD without going through GCC (despite all the badness
this entails...).  I'm not sure it's worth the effort but I need to
check my notes; I think I needed them for something to work right.

> This patch was tested with a bootstrap on athlon-pc-linux-gnu, as well
> as by building a cross compiler to mips-linux-gnu with and without
> sysroot.  The latter searched for headers, crt*.o and libraries within
> the sysroot, even after the entire tree was (i.e., the sysroot is
					     ^ moved, presumably.
> relative to the run-time location of the tree).
> 
> I'd like to check this in, and deprecate --with-headers and
> --with-libs in favor of --with-sysroot, and the various
> *STARTFILE_PREFIX* macros in favor of STARTFILE_PREFIX_SPEC.  A
> documentation patch will follow as soon as we have agreement on the
> deprecation terms.

I'm glad to see this patch!  It solves the biggest hosting issue that
we patch around locally here.  Relocatable installations have come a
long way since 2.x.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]