libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool wants to install LIBRARY.lai, but it doesn't exist


From: Marc Singer
Subject: Re: libtool wants to install LIBRARY.lai, but it doesn't exist
Date: Thu, 31 Mar 2005 09:49:20 -0800
User-agent: Mutt/1.5.6+20040907i

On Thu, Mar 31, 2005 at 10:39:09AM +0200, Ralf Wildenhues wrote:
> * Marc Singer wrote on Thu, Mar 31, 2005 at 10:10:15AM CEST:
> > On Thu, Mar 31, 2005 at 08:29:23AM +0200, Ralf Wildenhues wrote:
> > > Hi Marc,
> > > 
> > > * Marc Singer wrote on Thu, Mar 31, 2005 at 12:38:53AM CEST:
> > > > In the ltmain.m4 script, there is this code
> > > 
> > > You mean ltmain.sh, right?
> > 
> > It gets moved to .m4, yeah.  That's the one.
> 
> Almost right.  :)
> branch-1-5: ltmain.in -> ltmain.sh -> libtool
> branch-2-0/HEAD: config/ltmain.m4sh -> config/ltmain.sh -> libtool.

Hmm.  On Debian, the file is called /usr/share/libtool/ltmain.m4.

> > > It'd be nice to know
> > > - the exact libtool version used
> > 
> > 1.5.6
> 
> Please update to at least 1.5.14.

OK.

> > > - a small test case to reproduce the behavior (esp. Makefile.am snippet)
> > > - which of the details above trigger the behavior
> > >   (does the fact that you are cross-compiling do this?)
> > > - a `--debug' output of the `--mode=link' step of the library
> > > - `$(TOP)/scripts/config.guess`
> > > - contents of autogen.sh if that does fancy stuff other than a
> > >   autoreconf.
> > 
> > It turns out that the problem is kinda subtle.
> > 
> > > I need to remark that cross-compile support in Libtool is suboptimal
> > > ATM.  We want to change that, but it will take quite a bit of work.
> > 
> > I've noticed.  :-)
> > 
> > What's happening is that I'm building on a machine that has some of
> > the target libraries already built.  In some cases, the build of a
> > library will put the /usr/lib version in the .la file of the
> > cross-built package.  I've not spent much time figuring out the exact
> > circumstances that make that happen.
> 
> This description is, umm, well, a description.  Not precise enough to do
> anything.

Notice that I'm not asking for anything.

> > By making sure that all of the .la files are proper, I've eliminated
> > the error.  Part of the trouble is that I want to build with the
> > prefix as /usr so that the packages can install correctly.  As yet,
> > this may be something I have to relinquish.  It's kindofa nuisance
> > because libtool/autotools pass an -rpath $(libdir) for the linking
> > phase which means that the local system's libraries are always
> > available.
> 
> We should look into using some DESTDIR-like information at link time to
> override this.  Noone has volunteered for auditing libtool for this yet,
> the patches I've seen so far have done only patchwork.

IMHO, the DESTDIR mechanism is insufficient because packages assume
that $(prefix) is valid at build-time.  For example the .la files.  I
think the build model needs to be augmented to split the runtime paths
and the build-time paths.

> > The one thing that would help straight away would be a way to get the
> > autotools to put 'set -x' in libtool.  I've been doing it by hand.
> > It's been the only effect method of debugging.
> 
> Use --debug.  Set
>   LIBTOOLFLAGS=--debug
> when using a recent Automake.  Note that branch-2-0/HEAD Libtool have
> slightly better `set -x' support for ksh's.

Is there some place I should have looked to find this?  This is what I
mean about autotools being a challenge.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]