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

[Marc Singer]

On Thu, Mar 31, 2005 at 11:50:45PM +0200, Ralf Wildenhues wrote:
> * 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.

Sounds like a whole host of problems: ;-).

If the linkers hardcode paths, then all bets are off.  I'm not using
one of those systems and it is not generally desirable to only offer
the lowest common denominator of features.

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

Do you really think that we should stop innovating because some UNIX
platforms are static?  I'd rather see there be some Linux-only
features especially when they're so useful.  Also, the serious
cross-building issues are more about Linux that anything else.  No one
is putting Solaris on an ARM processor.  And bigger machines can all
self-host.

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

Not so.  Most of the makefiles override those environment variables.
Command line versions are ignored.  I cannot say much more about it,
but I can say that the Makefiles I've looked at are all this way.
Believe me, I looked for this option and found it to be unavailable.

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

Night.

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

That's exactly my point.  Your switch doesn't help much when autotools
makes it impossible to pass it in.  Hence, by reading from the
environment a variable *not* set by make programs, you make libtool
easier to debug.