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

[Marc Singer]

On Thu, Mar 31, 2005 at 10:20:12PM +0200, Ralf Wildenhues wrote:
> 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.

IMHO, what PC files do, the .la files can do better. 

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

  /usr/libraries
                /xrender
                        /include
                        /lib
                /cairo
                        /include
                        /lib

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.

> 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.
> 
> 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've got way too much else going on to hack on libtool.

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

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

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