Re: Problems with using libtool dependencies in opcodes

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Mar 10, 2004 at 02:52:02PM -0300, Alexandre Oliva wrote:
> On Mar 10, 2004, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > On Wed, Mar 10, 2004 at 03:29:29AM -0300, Alexandre Oliva wrote:
> 
> >> As soon as you configured your toolchain to install in /usr/local/lib,
> >> you're saying /usr/local is a directory that contains and/or will
> >> contain libraries for the host.
> 
> > That's the most useless behavior I've ever encountered.  The logical
> > corollary is that it is not possible to configure --prefix=/usr on a
> > build machine without implying that /usr/lib contains libraries for the
> > host, in other words, that it is not possible to cross-build native
> > system tools using libtool, with $build != $host, _by design_?
> 
> You're right.  This is a big problem.  Fortunately, it's not in the
> design, only in the implementation.
> 
> Ideally, libtool should not tack on run-time -L flags when linking
> with a library that is yet to be installed.  Unfortunately, this is
> quite difficult to implement.  Patches are most definitely welcome.

Hmm.

> > Let's try this from the other end then.  I want binutils installed on
> > my target in /usr.  I want to build it on a $build != $host system.
> > How would you recommend configuring it?
> 
> I'd configure it for a different prefix, and then take advantage of
> relocatability of the tree to get it to run on /usr/local.  Yuck.

I don't believe it will search the correct system library directories
if we do that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer