[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool wants to install LIBRARY.lai, but it doesn't exist
From: |
Ralf Wildenhues |
Subject: |
Re: libtool wants to install LIBRARY.lai, but it doesn't exist |
Date: |
Thu, 31 Mar 2005 23:50:45 +0200 |
User-agent: |
Mutt/1.5.6+20040907i |
* 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
- libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/30
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/30
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Ralf Wildenhues, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Ralf Wildenhues, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Ralf Wildenhues, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Ralf Wildenhues, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist,
Ralf Wildenhues <=
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Roger Leigh, 2005/03/31
- Re: libtool wants to install LIBRARY.lai, but it doesn't exist, Marc Singer, 2005/03/31