RFC: "Include .la files" rule for packages - revisited

[Michael Schwendt]

[Since some guess-work is involved here, I'd like to ask politely for
comments from "people in the know"...]

Some individuals will surely remember the times at fedora.us when it
was discussed whether to delete or include libtool archives (= *.la
files) in RPM packages. 

Neither Linux's build-time linkers nor its run-time linkers need these
.la files.

Not even libtool's own dlopen function needs these files anymore to
resolve library dependencies at run-time.

Almost everyone who has done application development with libtool and
automake (and friends) some time in the past, has run into problems
with .la files. Such as unresolvable inter-library dependencies or
build-time problems with moved or non-finalized or wrong libtool
archive files.

So, over time many people have build up the opinion that in RPM
packages, it's better to not include .la files. That reduced the
cases, where .la files are needed, to software which includes old
implementations of libtool dlopen, which strictly require .la files.

At fedora.us, a few such cases have been found during the first months
of activity. But, if memory serves correctly, also a few cases of bad
libtool files.

KDE, on the other hand, provides a library loader class, which depends
on availability of .la files to work correctly. Hence for most KDE
applications it is a good idea to not delete any .la files, because
else the app might fail loading its plugins/components at run-time.

A rule about .la files has never been set in stone. Backed up by many
packages in Red Hat Linux/Fedora Core, where .la files are not
included either, fedora.us packagers have decided to delete .la files
where no obvious breakage is discovered during QA.

Based on fedora.us bug #2284 I've discovered something which I didn't
know before. Could be that it's old news to KDE people:

It has been noticed that Imlib2, a library which uses libtool's API
for loading plugins at run-time, fails in Digikam 0.7. Imlib2 passes
an extension-less library name to lt_dlopenext, which then either
loads .la or .so files, if found. So, including .la files in the imlib
imlib package is not necessary. However, when called from within
Digikam, which is a KDE application, Imlib2's plugin loader fails to
find its *.so files. It does not even search for them. Why? It seems
KDE's libkdecore preloads some libtool related symbols to shield KDE
applications from accessing libtool's lt_dlopenext, lt_dlopen and
lt_dlopen_flag interface functions. A guess without reading the KDE
core source. But I found those symbols being mentioned in libkdecore
(did I guess right?). The shadow lt_dlopennext function from KDE
ignores *.so files and wants *.la files only. Hence Imlib2 fails.

This changes the .la/.so matter a good bit IMO. Where are we now? Do
we still delete .la files till we find out that it breaks something at
run-time? Or do we include .la files (it's a policy for Debian, isn't
it?) till we find that something doesn't build? What is worse?

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.667
loadavg: 1.55 1.35 1.31
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041116/36d4de4a/attachment.sig>