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-@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
