This is the mail archive of the gcc@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: gcc_tooldir


On Fri, Sep 12, 2003 at 03:21:31PM -0700, Ian Lance Taylor wrote:
> Marcus Comstedt <marcus@mc.pp.se> writes:
> 
> > > I've been testing relocation every release since 3.1, and it does work.
> > 
> > How?  If $prefix is /usr/local, then $libdir will be /usr/local/lib,
> > $libsubdir will be /usr/local/lib/gcc/target/3.4, and $gcc_tooldir
> > will be /usr/local/lib/gcc/target/3.4/../../../target.  If you move
> > gcc from /usr/local, then /usr/local/lib/gcc/target/3.4/ will not
> > exist and the entire path will be illegal.  How can that work?
> > How would it work less if $gcc_tooldir was /usr/local/target?

But it won't try to access /usr/local.  It will try to access /foo,
where you moved GCC.  Feel free to step through the code to get a
better idea of how.

> You set the environment variable GCC_EXEC_PREFIX.
> 
> http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Environment-Variables.html#Environment%20Variables
> 
> Using $(unlibsubdir) lets you move the entire tree and change only one
> environment variable.

Recent versions of GCC will correctly infer GCC_EXEC_PREFIX, also.

> If $gcc_tooldir is /usr/local/target, it is much harder to figure out
> how to parse that with respect to a changed GCC_EXEC_PREFIX, because
> you don't know how many layers to peel off the top.

This could actually be fixed now.  See make_relative_prefix, and the
way we handle the sysroot prefix it is is within $exec_prefix.  So
unlibsubdir _could_ be gotten rid of - if anyone is brave enough.

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