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 11:30:04 -0800
User-agent: Mutt/1.5.6+20040907i

On Thu, Mar 31, 2005 at 08:27:00PM +0200, Ralf Wildenhues wrote:
> Hi Marc,
> 
> * Marc Singer wrote on Thu, Mar 31, 2005 at 07:49:20PM CEST:
> > 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:
> > > 
> > > 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.
> 
> What?  packages.debian.org shows no such file.

You got that right.  

 drwxr-xr-x  2 root root   4096 2004-12-03 14:36 libltdl/
 -rw-r--r--  1 root root 210058 2004-10-26 03:02 libtool.m4
 -rw-r--r--  1 root root  13861 2004-10-26 03:02 ltdl.m4
 -rw-r--r--  1 root root 183935 2004-10-26 03:02 ltmain.sh

> > Notice that I'm not asking for anything.
> 
> Sure.  But I am.  I'm asking for a decent problem description.  :)
> To put it another way: I would _like_ to do something, or have something
> done about these issues.  As maintainer, vague problem reports or ones
> without feedback are almost like no bugreport at all.  Don't take this
> personal, it's just that there are enough mails written for nothing.
> (Not that I won't forget about bugs -- I'm not much better than the
> other side.)

I do this for a living, too.  I know how frustrating users' incomplete
reports can be.  My advice is to make it easier and more clear (aka
documentation) how to debug libtool.  The man pages (in 1.5.6) help
little.  I'm on both sides of this problem.  Yes, sometimes users are
ignorant and I'd rather not hear their content-free complaints.  And
yes, sometimes the software lacks features to aid in tracking
problems.  

At this point, all I can tell you is what I can identify.  For
example, the -rpath $(libtool) phrase in the Makefile is invalid:

E.g:
  libXrender.la: $(libXrender_la_OBJECTS) $(libXrender_la_DEPENDENCIES) 
        $(LINK) -rpath $(libdir) $(libXrender_la_LDFLAGS) 
$(libXrender_la_OBJECTS) $(libXrender_la_LIBADD) $(LIBS)

The more important problem is structural.  The use of .la files and
.pc files are incompatible with cross-compiling because of the use of
absolute paths.  I want to build packages that install at /usr on the
target, but can also be installed on a build host to aid in linking.

I'm not familiar with the problems that libtool solves.  Seems to me,
though, that there is redundancy between these .pc files and the .la
files.  It looks to me like creeping features.  Folks are adding to
the environment without taking in the whole picture.

At the moment, installing a newer version of libtool isn't possible
for me.  I'm depending on the host implementation for the time being
which is limited to the most recent version built for Debian.  I
intend to add, later, native tools to my cross-building environment.
Perhaps then I can give you better info.

> > 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.
> 
> I know.  That's why I wrote DESTDIR-like.  But point taken, I should've
> noted that more clearly.

No, I got you.  I just wanted to offer some insight into my
experiences so far.  I'm probably in the minority as someone
attempting to blaze new cross-building territory.  The othe tools such
as Openembedded, buildroot, and scratchbox just don't cut it.  They're
missing too many requirements.

There was a rancorous thread on the d-devel list about it.  Most
people think it is 'impossible' and 'invalid' to do cross-building.  I
*know* it is difficult and very frustrating at times.  I'd like it to
to be a reasonable choice.

> > > > 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.
> 
> Hmm. --debug is mentioned in `libtool --help' and in
>   info libtool Invoking libtool.
> LIBTOOLFLAGS has been added to Automake only very recently, but a doc
> update went in there as well.  Searching for `set -x' in libtool finds
> it right away as well.  Where would you have expected it?

Keep in mind that I'm building packages.  Adding switches to the
libtool command lines may be extremely tedious since it is difficult
to know which libtool invocation is failing.

The best way to handle this is to *not* depend on automake.  Libtool
can use an environment variable in it's own right.  For example, look
for the environment variable LIBTOOL_DEBUG and add those switches when
present.  This is something that can be added to the man page.

Cheers.




reply via email to

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