This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: introduce configure --with-sysroot
On Fri, Oct 25, 2002 at 01:41:52AM -0300, Alexandre Oliva wrote:
> On Oct 25, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>
> > But $host = $target. I built an i386 "cross" compiler, which is
> > something I use daily - from a desktop x86 environment to an embedded
> > one.
>
> If it targets an embedded system, then I don't see how target = host
> is really appropriate. I mean, host = target means you're creating a
> native compiler, so it's perfectly reasonable for it to search
> /usr/include.
Well, I often do it this way for consistency. Our "embedded" systems
are self-hosting; we want to be able to set up a standard cross
toolchain on i686-hardhat-linux for i686-hardhat-linux and have it
work. But for now we can just configure with
--host=i686-pc-linux-gnu and save --enable-cross for another time and
place, probably on the autoconf lists. They're having that discussion
again now I think...
So I'm OK with this part.
> How about introducing BUILD_SYSTEM_HEADER_DIR, defined to
> NATIVE_SYSTEM_HEADER_DIR if build==target and to SYSTEM_HEADER_DIR
> otherwise. Then we'd use BUILD_SYSTEM_HEADER_DIR for fixinc and in
> the limits.h test. In fact, there's no reason to rename the
> variable. SYSTEM_HEADER_DIR is *only* used for this purpose, so we
> can simply add a test for build = target when deciding whether to
> override the setting.
Not the clearest name, but I agree. I'll get back to this, really.
SYSTEM_HEADER_DIR is one of the biggest remaining warts in my GCC
builds. This only affects host-x-host compilers;
CROSS_SYSTEM_HEADER_DIR is used correctly now for the cross compiler,
which is nice (and recent I think).
> > No local changes in the test tree at all. It seems to me that the
> > directories in cppdefault.c:cpp_include_defaults should be affected by
> > %R, which means passing it to cc1 somehow.
>
> For a native compiler (even a cross-built host-x-host like the one
> you're building), CROSS_SYSTEM_HEADER_DIR is not used.
> CROSS_SYSTEM_HEADER_DIR is only used by the compiler on host-x-target
> systems, i.e., when host != target.
> > I can't tell if the prefix following code in cppinit.c and prefix.c is
> > supposed to be doing this, or not.
>
> It is not.
I just repeated the experiment using a MIPS target, and everything
worked, but it searches for C++ headers in the place that a
cross-compiler would rather than in the place that a native compiler
would:
/big/fsf/mips-bibinst/lib/gcc-lib/mipsel-hardhat-linux/3.4-bi/../../../../include/c++/3.4-bi
This is a bit unnatural to me; our headers would be in:
/opt/hardhat/devkit/mips/fp_le/target/usr/include/c++/3.4-bi
I suppose it's unreasonable to expect community GCC to do this, since
it certainly isn't going to install the built libstdc++ under target.
So we can work around this with symlinks here, and call that a loss.
So, aside from SYSTEM_HEADER_DIR, everything seems to work just fine
for the non-relocation case.
Back to where I was originally going, however: relocation. If I
configure with --prefix=/opt/hardhat/devkit/mips/fp_le/bibtest
and --with-sysroot=/opt/hardhat/devkit/mips/fp_le/target, the tree
isn't relocatable, just as you'd expect.
The first problem is:
(gdb) fin
Run till exit from #0 make_relative_prefix (
progname=0xbffff672 "/nevyn/big/hardhat/foo/mips/fp_le/bibtest/bin/mipsel-hardhat-linux-gcc",
bin_prefix=0x80566e0 "/opt/hardhat/devkit/mips/fp_le/bibtest/bin/",
prefix=0x8054540 "/opt/hardhat/devkit/mips/fp_le/target") at /opt/src/gcc/b-i-b/gcc/gcc.c:2417
0x0804d7c7 in process_command (argc=4, argv=0x805e828) at /opt/src/gcc/b-i-b/gcc/gcc.c:3981
3981 char *tmp_prefix = make_relative_prefix (argv[0],
Value returned is $2 = 0x805b420 "/nevyn/big/hardhat/foo/mips/fp_le/bibtest/bin/../target"
We give it progname and bin_prefix, and ask it to relocate prefix; it
gets what is patently the wrong answer. It went from fp_le/target to
fp_le/bibtest/target. I think the algorithm loses when prefix has
fewer components than bin_prefix and isn't above it... fixed by this
patch which I'm pretty sure is correct:
Index: gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.336.4.10
diff -u -p -r1.336.4.10 gcc.c
--- gcc.c 21 Oct 2002 17:51:57 -0000 1.336.4.10
+++ gcc.c 25 Oct 2002 17:12:05 -0000
@@ -2525,7 +2525,7 @@ make_relative_prefix (progname, bin_pref
obstack_grow (&obstack, prog_dirs[i], strlen (prog_dirs[i]));
/* Now build up the ..'s. */
- for (i = common; i < n; i++)
+ for (i = common; i < bin_num; i++)
{
obstack_grow (&obstack, DIR_UP, sizeof (DIR_UP) - 1);
obstack_1grow (&obstack, DIR_SEPARATOR);
After that, target_system_root is set correctly for the relocation.
We find relocated startfiles; we pass the correct value to the linker
for %R; etc.
The only problem is, cppdefault.c still has the original prefix
hardcoded. It doesn't get translated for just the reason you said it
wouldn't:
(gdb) p specd_prefix
$1 = 0xbffff5cd "/opt/hardhat/foo/mips/fp_le/bibtest/bin/../lib/gcc-lib/mipsel-hardhat-linux/3.4-bi/"
(gdb) p default_prefix
$4 = 0xbffff1b0 "/opt/hardhat/devkit/mips/fp_le/bibtest/lib/gcc-lib/mipsel-hardhat-linux/3.4-bi/"
There's a couple of easy ways to fix this:
1- move make_relative_prefix into some common place (preferably libiberty
eventually, so that I can use it in binutils!) and call it to
translate includes.
2- Pass some other option to serve the same purpose in a simpler
fashion, keeping all the logic in the driver.
2) is easier, but not sufficient, because $prefix/include and
$sysroot/usr/include are both in the includes list. $prefix/include
isn't relocated at the moment no matter what you do. So I spent a
little time hacking on 1). It wasn't immediately clear what to do with
-iprefix. What happens now:
- GCC generates in -iprefix if gcc_exec_prefix
- GCC honors command line -iprefix
- CPP relocates all directories that started with $(gcc_tooldir)
according to -iprefix
- CPP also searches all normal default directories
I left that unchanged but added another flag: if a sysroot was
specified (and found), pass a new flag to cc1, and
init_standard_includes will:
- Not search the normal location for default directories
- Continue to relocate directories that started with $(gcc_tooldir)
in the same way.
- Relocate all other directories using make_relative_prefix.
This gives me the result that I wanted, more or less. I'll clean it
up...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer