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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
