libtool bites us again (aka Libtool's Revenge, part II)

[Cesar Eduardo Barros <cesarb@web4u.com.br>]

The latest librep breakage showed us another of libtool's misfeatures: it
produces a .la file for each library. Originally, it was meant just for
development (giving the linking parameters, much like the .a and the .so
unversioned symlink), but I've heard that it's now used by libltdl to help
dynamic linking. This means that it now needs to be included with the library,
but since multiple versions of the library can be installed and the .la link is
not versioned, a conflict will happen.

My proposal:

Let's create a versioned version of the .la file, the same way it is done with
the .so file, and use it on the binary package. The .la file would be managed
like the .so. This means (librep example):

librep2:
	/usr/lib/librep.so.2.2.4
	/usr/lib/librep.so.2 -> librep.so.2.2.4		(created by ldconfig)
	/usr/lib/librep.la.2.2.4			(.la from librep2)
	/usr/lib/librep.la.2 -> librep.la.2.2.4		(created by postinst)
librep5:
	/usr/lib/librep.so.5.0.1
	/usr/lib/librep.so.5 -> librep.so.5.0.1		(created by ldconfig)
	/usr/lib/librep.la.5.0.1			(.la from librep5)
	/usr/lib/librep.la.5 -> librep.la.5.0.1		(created by postinst)
librep2-dev:
	/usr/lib/librep.so -> librep.so.2		(fixed within .deb)
	/usr/lib/librep.la -> librep.la.2		(idem)
librep5-dev:
	/usr/lib/librep.so -> librep.so.5		(fixed within .deb)
	/usr/lib/librep.la -> librep.la.5		(idem)

This will probably require changes in libltdl. It should search first for the
.la matching the soname (that is, librep.la.5.0.1 for librep.so.5 in the
example above). The symlinks help this search (which means if it wants to open
librep.so.5 it will try librep.la.5). If not found, it should fall back to the
unversioned .la file.

The problem is that then you would have to add the version (i.e. instead of
loading librep you would have to open something else). I suggest adding a
librep<ver>.la -> librep.la.<ver> to the library packages and making packages
that use libltdl to dlopen it use librep5 (or 2) instead of plain librep. It
would be a great fix to a bug, since if the major number changed the libraries
are by definition binary incompatible, and mixing them would just cause greater
mess.

We should discuss this with the upstream libtool developers (and in the
meantime tell them linux needs no fscking rpath), and maybe tell them to make
the .la symlink forest be created by libtool itself (instead of forcing us to
use ugly debian/rules copying/renaming/symlinking to create them), and also
include the version in the dlopenable names.

Well, this is just a suggestion. Anybody is welcome to suggest another
solution. RFC.

-- 
Cesar Eduardo Barros
cesarb@web4u.com.br
cesarb@dcc.ufrj.br