[Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies

[Simon McVittie]

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