Richard/others,
> > - libltdl's lt_dlopen() function can open .la files and use the
> > filename found in there. This isn't necessary on Debian systems,
> > since all architectures currently supported use .so as the extension
> > for shared libraries, but this might change in the future (Debian
> > GNU/Win32, anyone?).
> My reason for calling it broken: We already _have_ a versioning system
> for shared libraries. Libtool tries to supplant it, and it does it badly
> because .la filenames are not versioned. The feature you describe here
> would have to work at run-time, which means that only one .la file can
> be installed at run-time, and it might be for the wrong library version.
You need to distinguish between objects where the name is known at link
time ("libraries") and objects loaded dynamically at runtime
("plugins"). For libraries, the .la file is the same as the .so symlink:
There is only one, and this is the one the headers are installed for, so
that everyone building against the headers gets the correct library
version, regardless of what other versions are installed as well. Plus
as a benefit, you get additional version checking by libtool if both the
library and the program linking against the library support it. For
plugins, the .la file provides two features: A standardized name, so
that you can find your plugin by appending ".la" regardless of the
platform your program was compiled for (which is great for portability),
and that libltdl also handles libraries pulled in by your plugins (no-op
on GNU systems, but many others do this wrong).
> If we ever wish to port to a system that uses, for example, .dll as its
> library name extension, then we can easily introduce .so links to those
> dll files. There's no need to introduce yet another name space.
Windows has symlinks?
> > Number 2 is why I think we should keep them around. Some user may elect
> > to compile software himself, and removing the .la file would break his
> > build.
> Can you provide an example of this? I've never seen a build system
> (even one using libtool) that goes out of its way to break in such
> a case.
Hrm, I must admit I've never seen a real-world example, but IMO it is
okay for a configure script to parse .la files that were installed with
a library.
> > - the .la file is in the -dev package unless it is outside of the
> > library path, in which case the referenced .so file has to be in the
> > same package (binary plugin).
> You may have gathered that I disagree with this one :)
Why? The .la file should be where the .so (without version) is. For
libraries, that's the -dev package, for plugins, the package containing
the plugin (in the case of plugins, the versioning is done via the
installation path).
(Just to make it clear: I'm not a great friend of .la files either, but
they do belong to the interface of libraries and plugins built via
libtool, and we shouldn't change that interface if it doesn't break
anything)
Simon
Attachment:
pgpVHJGiRpi3l.pgp
Description: PGP signature