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, Aug 23, 2002 at 01:26:37AM -0300, Alexandre Oliva wrote:
> On Aug 22, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>
> > I second H-P's comment about --with-installed-sysroot.
>
> Tell you what... --with-sysroot might just as well refrain from
> copying anything, and GCC could set itself up so as to use the very
> pathname that was passed. Then, we'd just have to tweak our build
> scripts to do the copying from the outside. I happen to find this
> more elegant, even.
>
> The only potential gotcha is that one must pass ugly pathnames as
> arguments to --with-sysroot to get a relocatable tree: they must start
> with ${gcc_tooldir} = ${libdir}/${libsubdir}/../../../..., and the
> ${libsubdir} part is not easy to guess right from the outside.
Ugh. I don't like that at all.
> Alternatively, gcc could attempt to make the pathname relative, just
> like it does for gcc_tooldir, but I dislike this option. Perhaps we
> could only make it relocatable if it starts with ${exec_prefix}.
> How's that?
Ideal!
> That said, I'd rather get the patch in with minimal changes, and
> proceed from there. I know what we have now works, and most of it has
> been used successfully for a while. Introducing changes may break
> things in unexpected ways :-)
I've certainly got no problem fixing this after the patch goes in.
Meanwhile, let me explain my ideal desired behaviour; I don't think
it's possible.... there are three cases. Normally a tree looks like
this:
.../bin/target-gcc
.../bin/target-ld
.../target/usr/lib
(.../target/usr/lib/gcc-lib/.../ but that's for the built host-x-host
compiler, not for the cross compiler)
.../target/usr/include
Case 1:
The tree has a standard location in /opt/<product>/devkit/<target>,
Case 2:
It's fully relocatable and GCC assumes it is in the tree when finding
target.
Case 3:
I really, really wish it could find target in the default location...
when still in the build tree. Maybe key off -B./ on the command line?
Or off "bin" not being the last directory component. This case makes
running the testsuite very awkward.
Unfortunately, while Case 3 wants to check in the default location,
it's very important that Case 2 not do so.
> > I've got the necessary patches to GNU ld to do this.
>
> Cool! Don't tell me you also have patches that will let us not have
> to tweak the libc.so script in the target root, like we currently have
> to do! This would be awesome. ;-)
Well, no. But now that I think about it this shouldn't be hard, given
the idea of a sysroot.
> > I can clean them up and submit them if you want.
>
> Sure, please do! If we can unify on a single --with-sysroot option,
> even better.
When I have a little time, I'll do this - and see if I can sort out the
libc.so script too. Using a binutils equivalent to the %R trick
shouldn't be hard.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer