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

[Ralf Wildenhues]

* Marc Singer wrote on Fri, Apr 01, 2005 at 12:32:04AM CEST:
> 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:
> > 
> > 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: ;-).

ACK.

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

ACK.

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

No.  I merely tried to describe the status quo.

> I'd rather see there be some Linux-only
> features especially when they're so useful.

Yes, me too.  Whereever possible, I'd like to avoid gratuitous breaking
on other systems.  I.e., allow graceful degradation if possible.  Where
impossible, at least tell the user that what he does will not work
everywhere.  We do this in a number of situations.

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

Sure.

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

The portable form to say `make foo=bar' is
  env foo=bar make -e
as noted in `info Autoconf Limitations\ of\ Make'. Does it help you now?

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

With the same argument, I could want compilers to use an additional flag
to read CFLAGS from, etc.

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

What clobbers the build directory?  How?

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

Let's see the answer to the question above, and the judge again.

Regards,
Ralf