getting rid of libtool-brokeness
Hi,
we had a couple of ideas today how we could make libtool behaving
better than in http://bugs.debian.org/539687
This mail is to memorize all the ideas, none of them was considered
good (and all have obvious disadvantages).
First, what does libtool do, and why does it hurt us:
libtool does create .la-files, and put into dependency_libs lines like
dependency_libs=' /usr/lib/libaubio.la /usr/lib/libsndfile.la
/usr/lib/libFLAC.la /usr/lib/libjack.la /usr/lib/libfftw3f.la
/usr/lib/libsamplerate.la /usr/lib/libasound.la -lm -ldl -lpthread'
By this mechanismn it recursivly includes any dependency_libs-line
build-dependencies have.
Advantage is that this eases compilation of static libraries, and also
allows to dynamically opens the lib via libltdl (and has a bunch of
positive issues on architectures without proper support for dynamic
libs etc, but that doesn't matter inside of Debian). So advantages of
libtool *inside* of Debian are not so many.
Often libtool will compile libraries both statically and dynamically,
or at least the source code files.
A specific feature is that libtool is copied into the source code of
any package, so whatever we do needs to be acceptable for upstream
development, and for shipping to non-Debian environments.
Disadvantage of the current approach is that we have "fun" if a
.la-file disappears (any depending package needs to be recompiled, and
in correct order), if a .la-file has wrong entries (one might end up
with packages FTBFS even though all build-deps are there, but libtool
wants something else), and that packages link to libraries where they
don't need to directly, thus making it harder to determine "what are
the real direct dependencies".
1. Do nothing: easiest to implement, but our life will stay hard.
2. Having the "central" packages making "dependency_libs" empty:
Breaks compiling static compilations, every such package needs to be
fixed by hand.
3. Having a snippet in debhelper and cdbs: still breaks static
compilations, but makes fixing the dynamic packages easier.
4. as 3, but enable it by default: breaking on the static ones is
harder (because lots of packages FTBFS at the same time), but normal
packages don't need any work.
5. try to push some functionality upstream to libtool that allows to
ignore the content of dependency_libs during compilation of dynamic
libs. Probably a bit hard to do - best would be some environment
variable that would default to "ignore that". (Unless that goes
upstream, there is not much that we could do, as libtool is statically
incorporated in source.)
I hope I did summarize our todays discussion correct.
For me now the next question is: If we dump any dependency_libs line,
how many packages will get broken by that?
One possibility might be a full recompile of the current archive, and
another with the same archive but with
find $libpath -name '*.la' | xargs sed "s/^dependency_libs=.*/dependency_libs=''/"
after installation of the dependencies and before starting
dpkg-buildpackage, and see how many additional failures we will get.
Cheers,
Andi
Reply to: