On 13/08/15 10:44, Andreas Tille wrote: > However, from your mail it seems that there is some issue with libmuscle > which I do not understand and where I have no idea how to fix. Could > you be so kind to give some more detailed hint how this can be fixed and > why the package is hidden from the transition tracker?
The package is not in the transition trackers *because* of the linking issue I reported: its dependencies are wrong. >> dpkg-shlibdeps: warning: symbol _ZN6muscle4QuitEPKcz used by >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in >> none of the libraries >> dpkg-shlibdeps: warning: symbol _ZNK6genome10gnSequence6subseqEyy used by >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in >> none of the libraries >> dpkg-shlibdeps: warning: symbol _ZN6muscle8DistFunc8SetCountEj used by >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in >> none of the libraries >> dpkg-shlibdeps: warning: symbol _ZN6muscle10RefineVertERNS_3MSAERKNS_4TreeEj >> used by debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 >> found in none of the libraries >> dpkg-shlibdeps: warning: symbol >> _ZNK5boost9iostreams18mapped_file_source4dataEv used by >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in >> none of the libraries >> dpkg-shlibdeps: warning: symbol >> _ZN5boost10filesystem4path27m_erase_redundant_separatorEj used by >> debian/libmems-1.6-1/usr/lib/i386-linux-gnu/libMems-1.6.so.1.0.0 found in >> none of the libraries libMems-1.6.so.1.0.0 should have been linked to the libraries it depends on, something like gcc -o libMems-1.6.so.1.0.0 something.o someother.o \ -lmuscle -lgenome -lboost-filesystem (those library names are just guesses and probably wrong, but hopefully you get the general idea), but in fact it was linked without specifying the libraries it depends on, more like gcc -o libMems-1.6.so.1.0.0 something.o someother.o As a result, the .so does not have the correct DT_NEEDED headers describing the libraries that it depends on (use "objdump -Tx" to see those). As a result of that, dpkg-shlibdeps produces those warnings, and does not generate the dependencies that it should. It does not appear in the transition trackers because each transition tracker uses dependencies to find the packages that depend on the transitioning library. At the moment, libmems-1.6-1 only depends on libc, libgcc and libstdc++, and there is nothing in its metadata to indicate that it should be involved in the boost or libgenome transitions. The solution is something like this in the Makefile.am: libMems_1_6_la_LIBADD = $(DEPS_LIBS) You might also need to append $(BOOST_LIBS) or -lboost-filesystem or something, I don't know how Boost is meant to work. There might also be additional libraries among the "more warnings" that dpkg-shlibdeps suppressed. The general principle is to keep adding libraries until dpkg-shlibdeps stops producing "found in none of the libraries" warnings :-) If you add -no-undefined to the LDFLAGS, the linker will fail "hard" (FTBFS) when it encounters missing dependencies, instead of continuing to link a partially broken library. This flag is usually a good idea where possible; it can be used for executables and most shared libraries, but cannot be used for some loadable modules (e.g. Python extensions) or for circularly dependent libraries. S