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

[Ralf Wildenhues]

* Marc Singer wrote on Thu, Mar 31, 2005 at 10:59:13PM CEST:
> On Thu, Mar 31, 2005 at 10:20:12PM +0200, Ralf Wildenhues wrote:
> 
> > - .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.
> 
> IMHO, what PC files do, the .la files can do better. 

ACK.

> > - .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?).
> 
> I don't see why that's the case.  There is no reason that those paths
> have to be absolute.  In fact, it should be possible to put complete
> packages into subdirectories.  The linking phase can specify where to
> find these libraries.  No need for absolute paths because it is
> handled at link-time by replacing the usr/libraries component with
> something else.  The dependency files only need to say what libraries
> are necessary and, perhaps, what versions.

But you do know what -rpath is, right?  And that it is necessary on some
systems to specify where to find the deplibs?  That some linkers
hardcode the directories you specify with `-L' into the shared object?
Sure: from libtool's POV all of this happens at link (or relink) time,
not at configure time.

> I think this is a better solution because it means that a user can
> install more that one library version.  IMHO, it is all about
> formulating the problem and goals such that a flexible solution is
> found.  The current state of affairs, while better than MSWindows, is
> showing it's weaknesses.

It's kind of a more-or-less portable subset.

> > > 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.
> 
> I'm working on Makefiles that perform the builds.  These scripts don't
> call libtool, they call make.  If I need to edit a makefile to perform
> the test, it is hard to know where to make the change.  An environment
> variable sidesteps the problem by allowing me do so this:
> 
>   make LIBTOOL_DEBUGFLAGS=--debug -C build/package all
> 
> such that I don't have to worry about automake or anything else.

Huh?  I still don't see the point.
If your Makefile was created by automake, you do
  make LIBTOOLFLAGS=--debug ...
and if not, maybe you can still do
  make LIBTOOL='path/to/libtool --debug'
or what not.  If you wrote Makefile or Makefile.in yourself, well, put
  $(LIBTOOLFLAGS)
after every $(LIBTOOL)!  You surely would not have hardcoded the path to
libtool into your Makefile, right?

Show me the improvement gained by a libtool-read environment variable.

> What
> I've been doing is inserting set -x at the top of libtool script after
> it is built by autoconf/autogen.  Messy, but reasonably reliable.
> Note, too, that I tends to clobber the whole build directory over and
> over again in order to get the scripts correct.

I don't understand this (but it is getting late).

> > > 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.
> 
> Interesting that that isn't your manpage.  Note, though, that it isn't
> that I didn't know there was a debug switch, it's that there isn't a
> way to apply it.

Which then has almost nothing to do with libtool, but with your makefile
or makefile generator or your other build system.

Regards,
Ralf