This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Updates to --with-sysroot support
On Wed, Nov 06, 2002 at 03:15:00PM -0200, Alexandre Oliva wrote:
> On Nov 4, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>
> > - Fixes an undocumented behavior in cppinit.c which I consider to be a bug.
> > If -iprefix was used to change the compiler prefix, then first the
> > standard include directories which begin with the prefix were searched
> > (using the relocated prefix); then all directories were searched in order
> > (using the original prefix). This means that -iprefix'd versions of
> > GCC_INCLUDE_DIR (that's -iprefix's prefix followed by "include", folks)
> > would be searched before GPLUSPLUS_INCLUDE_DIR. Oops.
>
> Oops, indeed :-)
>
> > I changed this so that the order is preserved, and unrelocated versions
> > are not searched.
>
> I'm not sure like the second part. Couldn't it break compiles within
> the build tree, or at least disrupt the build-tree staging area that
> we've been discussing about. Ideally, I think we should search the
> original pathname, just let the relocated one be searched first, but I
> don't have a strong opinion on this, and could be easily convinced
> that it's a bad idea. In fact, I've almost managed to convince myself
> of it :-)
Well, let me add a helping hand... :) On my system, I may have several
versions of a product installed. They're the same product, and they
normally install in the same place. But for development purposes, I
keep them in separate places.
It's pretty important to me that one of my relocated compilers - no
matter what may be wrong with its installation, etc. - should not
search the original installation path. Where it may find incompatible
versions of headers and libraries, and in general confuse me.
It can't affect compiles within the build tree; this is only applied to
the list of include directories in cpp_include_defaults. None of those
are originally pointing into the build tree.
> > - Searches prefixed versions of LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR,
> > and STANDARD_INCLUDE_DIR.
>
> > - Relocates those prefixed directories by passing -isysroot to cc1 to
> > override the normal prefix.
>
> Yay!
>
> > - Fixes a bug in make_relative_path; it only worked if exec_prefix was the
> > same as or inside of prefix, which generally worked for exec_prefix
> > but won't now that we use this function for the sysroot too.
>
> Excellent.
>
> > With this and some -rpath-link's, I can build a complete relocatable sysroot
> > compiler without having to specify the sysroot via $gcc_tooldir. How's it
> > look?
>
> > * doc/invoke.texi (Spec Files): Update description of %I.
>
> If I understand your change to make_relative_path correctly, you may
> want to tweak the part of the docs that says that --with-sysroot must
> be a subdirectory of exec-prefix or gcc_tooldir, and arrange for the
> top-level to no longer turn it into a gcc_tooldir-relative reference
> for relocatability. In fact, I suspect a number of relocatability
> issues may have become much simpler with this change. So much so that
> I fear there may be something that justified the libsubdir-based
> references that both of us are missing :-(
Blech, I knew I forgot something. Yes, here's the install.texi patch;
it deletes the unpleasant bit that got me started on this in the first
place, and documents the relocation.
You didn't commit the bits to turn it into a gcc_tooldir-relative
reference, did you? Or rather, I noticed that you committed the
gcc/configure bits, but not the gcc/configure.in bits; and I think the
gcc/configure bits were the error.
> Anyway, way to go, /me says! No that I can approve this patch, but if
> I could, I would :-)
So will someone else? :)
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2002-11-06 Daniel Jacobowitz <drow@mvista.com>
* install.texi (--with-sysroot): Update comment about
relocation.
Index: install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.136.2.6
diff -u -p -r1.136.2.6 install.texi
--- install.texi 28 Oct 2002 19:48:54 -0000 1.136.2.6
+++ install.texi 6 Nov 2002 17:29:34 -0000
@@ -890,16 +890,9 @@ searched in there. The specified direct
install tree, unlike the options @option{--with-headers} and
@option{--with-libs} that this option obsoletes. The default value,
in case @option{--with-sysroot} is not given an argument, is
-@option{$@{gcc_tooldir@}/sys-root}. Starting the pathname with
-@option{$@{gcc_tooldir@}/}, in such a way that this variable is not
-expanded by the shell, but rather by the gcc Makefile, enables the
-target sysroot directory to be relocatable along with the entire
-install tree, but it will require the gcc tool directory to be created
-@emph{before} the build is started. This directory, as well as its
-intermediate pathnames, can be easily created by running @command{make
-install-gcc-tooldir} the gcc build directory. This is not done
-automatically to avoid touching the install tree without explicit
-permission.
+@option{$@{gcc_tooldir@}/sys-root}. The system root path will be relocated
+along with the compiler's other search paths if the compiler's installation
+directory is moved.
@item --with-headers
@itemx --with-headers=@var{dir}