Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies
all changes pushed. The new boost.m4 solved my problem, but adding the libraries in the link dependencies was still needed. The package builds and the boost libraries are also linked. BTW it was _LIBS not _LIB, so no AC_SUBST needed. However, building a package I got another error devlibs error: There is no package matching [libGenome-1.3-0-dev] and noone provides it, please report bug to d-shlibs maintainer devlibs error: There is no package matching [libMUSCLE-3.7-1-dev] and noone provides it, please report bug to d-shlibs maintainer never seen this one before. t seems this d_shlibs expects the soversion in the dev-package name. I left another patch in the git history that deals with a conflict between boost::make_tuple and std::make_tuple of c++11. I would have left it in the build, but somehow I didn't get the patch to have the right line endings. Since C++11 is not enabled by default, this is currently not a problem. Best, Gert
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On Mon, Aug 17, 2015 at 12:11:23AM +0200, Gert Wollny wrote: On 13.08.2015 18:17, Andreas Tille wrote: I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( After digging through m4/boost.m4 I'm quite confident that it is indeed the AC_SUBST that is missing, because with BOOST_FLYEIGHT they do it but not with BOOST_FILESYSTEM. However, I an not confirm this, because for some reason for me configure fails with configure: error: invalid value: boost_major_version= I wonder whether there is some boost.m4 we could steal somewhere. Kind regards Andreas. -- http://fam-tille.de
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
Am Montag, den 17.08.2015, 00:11 +0200 schrieb Gert Wollny: On 13.08.2015 18:17, Andreas Tille wrote: I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( After digging through m4/boost.m4 I'm quite confident that it is indeed the AC_SUBST that is missing, because with BOOST_FLYEIGHT they do it but not with BOOST_FILESYSTEM. However, I an not confirm this, because for some reason for me configure fails with configure: error: invalid value: boost_major_version= Best I had this too one time, and in may case it has been an outdated boost.m4. -- tobi
Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On 17.08.2015 09:14, Andreas Tille wrote: I wonder whether there is some boost.m4 we could steal somewhere. Kind regards Andreas. Well, there is upstream https://github.com/tsuna/boost.m4 I will now try with this one. Andreas, I you didn't push your changes, right?
Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On Mon, Aug 17, 2015 at 10:20:53AM +0200, Gert Wollny wrote: On 17.08.2015 09:14, Andreas Tille wrote: I wonder whether there is some boost.m4 we could steal somewhere. Kind regards Andreas. Well, there is upstream https://github.com/tsuna/boost.m4 I will now try with this one. Cool. Andreas, I you didn't push your changes, right? I have not any helpful commit. That's my last one: commit c5973e8409a029a76cfbf65219b2ca83c1b66100 Author: Andreas Tille ti...@debian.org Date: Wed Aug 12 16:47:46 2015 +0200 Try gcc-5 transition but can not build for the moment due to boost transition issue All other stuff was non-helpful poking in the dark. Kind regards Andreas. -- http://fam-tille.de
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On 13.08.2015 18:17, Andreas Tille wrote: I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( After digging through m4/boost.m4 I'm quite confident that it is indeed the AC_SUBST that is missing, because with BOOST_FLYEIGHT they do it but not with BOOST_FILESYSTEM. However, I an not confirm this, because for some reason for me configure fails with configure: error: invalid value: boost_major_version= Best
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
Package: libmems-1.6-1 Version: 1.6.0+4725-1 Severity: serious Justification: Policy 10.2 From the i386 buildd log: dh_shlibdeps -a 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 dpkg-shlibdeps: warning: symbol _ZN6muscle18SetSeqWeightMethodENS_9SEQWEIGHTE 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 _ZN6muscle8TextFileC1EPKcb 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 _ZN6genome10gnSequence13setContigNameEjRKSs 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 _ZNK6muscle3MSA11GetSeqIndexEj 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: 79 other similar warnings have been skipped (use -v to see them all) Among other things, this causes libmems to not show up properly in the https://release.debian.org/transitions/html/auto-libgenome.html transition tracker, so the release team will not schedule the necessary binNMUs for it. Regards, S
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
Hi Simon, thanks for your bug report. Yesterday I noticed that libmems needs a transition but it needs to wait for boost libs first. 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? Kind regards Andreas. On Thu, Aug 13, 2015 at 09:45:48AM +0100, Simon McVittie wrote: From the i386 buildd log: dh_shlibdeps -a 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 ... -- http://fam-tille.de
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
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
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
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
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On 13/08/15 15:06, Andreas Tille wrote: +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ + SUBDIRS = libMems Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la is built and the rest of the libMems_la_WHATEVER variables appear. S
Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On Thu, Aug 13, 2015 at 03:40:21PM +0100, Simon McVittie wrote: On 13/08/15 15:06, Andreas Tille wrote: +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ + SUBDIRS = libMems Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la is built and the rest of the libMems_la_WHATEVER variables appear. I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( Kind regards Andreas. -- http://fam-tille.de
