[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
Attachment:
pgp4lGxcXJHX5.pgp
Description: PGP signature
