Re: don't install .la do install .so

[Andrew W. Nosenko]

On Mon, Mar 21, 2011 at 21:13, Paul Elliott
<address@hidden> wrote:
> On Monday, March 21, 2011 12:51:11 pm Nick Bowler wrote:
>> On 2011-03-21 10:52 -0500, Paul Elliott wrote:
>> > According to the Fedora Packaging:Guidelines
>> > http://fedoraproject.org/wiki/Packaging/Guidelines
>>
>> > .la files should not be installed:
>> This is a task for the Fedora packagers, and not for developers to bake
>> into their makefiles.  See below.
>>
>> > How do I create a Makefile.am for a shared library so that make install
>> > will not install the .la file but will install the .so?
>>
>> Please do not do this.  The .la files are necessary except for very
>> special situations.  Since Fedora has complete control over how packages
>> are configured and installed, they can afford to make the necessary
>> arrangements rendering the .la files unnecessary.  But when your
>> package is configured by a user, you have no way of knowing a priori
>> whether or not they need the .la files.
>>
>> See the autotools FAQ entry on this:
>>
>>
>> http://www.gnu.org/software/automake/faq/autotools-faq.html#What-are-these
>> -_002ela-files-for-and-can-I-safely-remove-them_003f
>>
>> In particular,
>>
>>    Removing usually only works OK if done in directories which the
>>    runtime linker searches by default anyway (otherwise you might need
>>    to set LD_LIBRARY_PATH or an equivalent variable) and only on systems
>>    where the runtime linker loads indirect library dependencies
>>    automatically (includes GNU/Linux, GNU, Solaris).
>
> Well, the openSUSE:Shared library packaging policy
> http://en.opensuse.org/openSUSE:Packaging_guidelines#Libraries
> says the same thing. They seem to have copied the fedora document verbatim on
> this.
>
> Also the debian policy Manual
> http://www.debian.org/doc/debian-policy/ch-files.html
> says the same thing for most cases:
>> Packages that use libtool to create and install their shared libraries
>> install a file containing additional metadata (ending in .la) alongside
>> the library. For public libraries intended for use by other packages,
>> these files normally should not be included in the Debian package, since
>> the information they include is not necessary to link with the shared
>> library on Debian and can add unnecessary additional dependencies to other
>> programs or libraries.[71] If the .la file is required for that library
>> (if, for instance, it's loaded via libltdl in a way that requires that
>> meta-information), the dependency_libs setting in the .la file should
>> normally be set to the empty string. If the shared library development
>> package has historically included the .la, it must be retained in the
>> development package (with dependency_libs emptied) until all libraries
>> that depend on it have removed or emptied dependency_libs in their .la
>> files to prevent linking with those other libraries using libtool from
>> failing.
>
> All the distros do say that if you are not installing the library in one of
> the standard places, like, /lib /usr/lib, then you should leave the .la file
> there. But all the distros seem to basicly agree that in the default case
> where your library is going to be linked by other programs and you are
> installing in the usual places, the la file should be removed.
>
> It seems dumb to have make install install a file only to have the distro
> remove it, is there anyway to tell make install not to install it?
>

Excuse me again, but reference to Debian and SUSE doesn't add
anything.  You may add yet another 300 Linux disrtibutions that
declared the same rules about .la files.  But it won't add anything
either.

Inter-library dependency handling is a property of ld.so.  All Linux
distributions shares the same ld.so (different versions, but the
same).  Therefore, adding more distributions to the list doesn't add
anything to the my question: how you plan to handle inter-library
dependencies on the systems where ld.so does NOT support such things?

And it is just one and _very_ simple question.

PS. I totaly agree that .la in theirs current form are not very
convinient.  Indeed, not the .la itself, but the way, how libtool
works with them.  But instead of discussing whether to remove them, I
would prefer to see discussion, how to make libtool more convinient
(more ld(1) like, i.e. how to support access to the
/path/to/libname.la as -L/path/to -lname instaed of forcing to specify
the full path with full name.)

-- 
Andrew W. Nosenko <address@hidden>