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

[Ralf Wildenhues]

Hi Marc,

* Marc Singer wrote on Thu, Mar 31, 2005 at 09:30:04PM CEST:
> On Thu, Mar 31, 2005 at 08:27:00PM +0200, Ralf Wildenhues wrote:
> > * 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:
> 
> > > 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.

Oh, I don't do this for a living.

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

OK, I see we disagree less than we thought.  :)

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

Sort of.  Couple of notes:
- .pc files come from pkgconfig.  While a seemingly easy tool and easy
solution, its incapable to solve some more complex problems.  (You seem
to have noted that already.)  pkgconfig has nothing to do with the
Autotools autoconf/automake/libtool except that by chance there might
now be some maintainer overlap and that there has been the idea of
absorbing its functionality into Libtool.
- .la files are created by libtool.  They have absolute files, and that
sucks for users, but one has to know that it's not portably possible to
create truly relocatable shared libraries and shared-linked programs
(Yes, I have heard of this weird relocation package on some linux?).
So, in general there is no way to eliminate absolute paths.
What is necessary is a good way to express a different way of prefixing
and maybe also saying "this portion of the path is called differently,
at the moment".  I think this is all you will need.

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

Sure.

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

See above.  Search for 'aberration called pkg-config' on this list. :)

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

OK.  If you intend to do serious work on Libtool, be encouraged to use
branch-2-0 or HEAD.  There's been some restructuring and some cleanup.

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

You are not attempting completely new territory.  People have come up
and posted cross-compilation bugs.  Often even with patches to solve for
their specific setting.  But they missed the bigger picture, so that did
not help much.

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

That'd be *great*.

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

OK.  What would be better?

> The best way to handle this is to *not* depend on automake. 

We don't depend on automake.  All it does is call

  $(LIBTOOL) $(LIBTOOLFLAGS) --tag=CC --mode=compile $(CC) ...

and if you have a different build system, make that provide you with a
possibility to set options.

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

I may be dense, but in what way is an environment variable superior to a
command line switch?  This is an honest question, I would change it if I
saw an improvement.

> This is something that can be added to the man page.

We don't have a man page.  We are sorry if the Debian-provided manpage
is out of date.  It does contain --debug, however.

Regards,
Ralf