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


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