* 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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
