Re: PROPOSAL: libtool archive (`*.la) files in `-dev' packages
Hello again.
Some more food for thought:
On 06-May-99 Joey Hess wrote:
> Ossama Othman wrote:
>> Certainly libtool is fully capable of linking against shared libraries which
>> don't have .la files, but being a mere shell script it can add considerably
>> to the build time of a libtool using package if that shellscript has to
>> derive all this info[[r]]mation from first principles for each library every
>> time it is linked.
>
> Hm. If all the gain we get is the possible advantage in speed of
> reading/sourcing a .la file versus running objdump -p, I'll have to oppose
> this proposal to ship .la files with debian. That's got to be on the order
> of only a second or so per build saved.
Make that a second or so per .la-less libtool library linked, perhaps an order
of magnitude higher on a slow host. And the work is done twice (or more), once
to generate he .la file (which is discarded) and again to rebuild the lost
information every time the library is linked into another object.
You're not thinking in a libtool way here. Remember that the whole raison
d'etre for libtool is to allow package authors to treat shared libraries in
exactly the same way on any host, no matter what features shared libraries
have on the package installer's host. As it happens elf shared libraries are
among the most featureful that libtool supports, so libtool doesn't have to
actually implement missing features (yet... see the end of this message), it
merely has to wrap them in its own portable (and that is the key issue at stake
here) interface, which in turn relies on the .la files to store metadata. So,
yes, one can certainly do most anything with an elf library that one can do
with a a libtool library, but, then one is no longer writing a portable package
because most build environments do not have elf shared libraries, so by using
raw elf features and bypassing the libtool interface, the package must either
implement libtool's portability itself (like tcl for instance), or be limited to
working on only hosts that provide elf shared libraries.
>> With the advent of libtool-1.4 (and to a lesser extent libtool-1.3), the .la
>> files will also store information about inter-library dependencies which
>> cannot necessarily be derived after the .la file is deleted. Thomas can
>> probably explain this a lot better than I can, so I won't muddy the waters
>> with a poor example of my own.
>
> As far as I can see linux's shared library format allows specification of
> inter-library dependancies. So I hope an example is forthcoming..
Sure it does, but libtool libraries implement inter-library dependencies on
non-elf build hosts *with the same interface*. And being able to provide that
portable interface relies on the metadata in the .la files.
>> objdump will get soname information from an elf library, and version numbers
>> are encoded in the filenames. Of course, this doesn't help much if the
>> version numbering system is not known, or is inconsistent (say with mixed
>> libtool and non-libtool versioned libs where the .la files have been
>> removed).
>
> This looks like a real benefit.
Gord mentioned something that reminded me of another benefit: libtool provides
libltdl, a(nother) wrapper interface which allows a package to use the dlopen
interface with impunity. That is, by using libltdl's dlopen interface, a
package can be built to dynamically load modules, even on hosts which do not
have shared libraries. Or, more pertinent to Linux, where the package author
needs or wishes to statically link binaries and libraries, but still be able to
dlopen the statically linked libraries... perhaps where security is an issue
and LD_PRELOAD must be defeated. For this mechanism to work fully (that is
with libraries not shipped with the package) the meta-data in the .la files is
required.
Another point which has just occured to me, and which is of particular import
to Linux is the partially implemented (slated for full implementation
in libool-1.4) selective symbol export feature of libtool. This allows a
(libtool) library author to limit the symbols which are exported from a library
with respect to being dlopened. The symbol lists will be held in the .la file
on hosts which do not support this natively (such as linux elf).
I hope this is of help in your decision.
Cheers,
Gary.
--
___ _ ___ __ _ email:gary@oranda.demon.co.uk
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary@gnu.org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ pgp-2 public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/pgp
Reply to: