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

[Andreas Tille]

Hi mentors,

I have some problem with automake configuration to link library
symbols properly.

On Thu, Aug 13, 2015 at 11:31:02AM +0100, Simon McVittie wrote:
> 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),

I confirm that the idea is understood.

> 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 :-)

I have tried the following quilt patch


--- a/Makefile.am
+++ b/Makefile.am
@@ -10,5 +10,7 @@ projects/libMems.vcproj
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = libMems- at GENERIC_API_VERSION@.pc

+libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
+
 SUBDIRS = libMems

--- a/configure.ac
+++ b/configure.ac
@@ -97,6 +97,7 @@ BOOST_IOSTREAMS
 dnl Get location of libGenome Headers
 PKG_CHECK_MODULES(DEPS, libGenome-1.3 >= 1.3.1  libMUSCLE-3.7 >= 1.0.0)
 AC_SUBST(DEPS_CFLAGS)
+AC_SUBST(DEPS_LIBS)

 dnl Check for OpenMP
 #AX_OPENMP()



with no visible change in the build (I also tried the versioned
libMems_1_6_la_LIBADD with the same zero effect).  I suspect that also
libMems-1.6.pc.in might need some love but I have no idea how.
 
> 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.

I'll add this but would like to fix this first that way.
 
Kind regards

       Andreas.

-- 
http://fam-tille.de