On 23 August 2018 at 15:30, Steve Langasek wrote: | On Thu, Aug 23, 2018 at 05:15:48PM -0500, Dirk Eddelbuettel wrote: | > | In Ubuntu, I noticed that pscan-tfbs was failing to build due to unresolved | > | symbols in libgsl.so. I don't know if the specific build failure is | > | reproducible in Debian, but I can confirm that libgsl.so.23 is also | > | underlinked in Debian resulting in unresolved symbols, which is not supposed | > | to be the case for shared libraries: | | > Any reason why? This particular scheme (of not assigning a major the | > auxiliary library libgslcblas) has been in place for a decade+. Could it be | > that my recent attempts of getting majors into package (where I was sloppy) | > caused this? | | I haven't looked closely enough at the issue to root cause it, but I do see | that the problem is present even in libgsl.so.19 from gsl 2.1+dfsg-2. It's | possible that before now every reverse-dependency of gsl happened to pass | -lgsl -lgslcblas options in the correct order to not trigger a failure at | build time (with the Ubuntu toolchain, which is more strict than Debian's). | pscan-tfbs is a new package and passes -lgslcblas -lgsl which is the wrong | order, so that is /also/ a bug, but only one of the two bugs needs to be | fixed in order to let pscan-tfbs build.
Quite likely. | > | Please consider applying the attached patch to the gsl package in Debian. I | > | have uploaded it to Ubuntu to fix the build failure of the reverse | > | dependency. | | > | Corresponding changelog entries for these changes: | | > | * debian/patches/gsl-cblas-linkage.patch: add missing linkage on | > | libgslcblas to libgsl.so. | > | * specify AUTOMAKE and ACLOCAL to dh_autoreconf, to work around upstream | > | hard-coding of automake-1.13. | | > Sounds good to me. I think I'll build with this evening. | | > Now it is time to confess that I am an utter noob when it comes to libtool, | > so I am not sure I fully grok what your patch does, besides "reintroducing" | > these two sibbling libraries to each other. | | The net effect is that when libgsl.so is being built, it's built with a | -lgslcblas linker option. | | Effectively, you could also drop the manual dependency from libgsl23 to | libgslcblas23, since dh_shlibdeps will now generate the correct dependency | for you. The fun bit that there is only ever libgslcblas0 -- it never changes: edd@rob:~$ dpkg -L libgslcblas0 | grep "\.so" /usr/lib/x86_64-linux-gnu/libgslcblas.so.0.0.0 /usr/lib/x86_64-linux-gnu/libgslcblas.so.0 edd@rob:~$ dpkg -L libgsl23 | grep "\.so" /usr/lib/x86_64-linux-gnu/libgsl.so.23.0.0 /usr/lib/x86_64-linux-gnu/libgsl.so.23 edd@rob:~$ | > Lastly, how strong do you feel about the patch? Should we talk to upstream | > about it? | | I'm happy to advocate for this patch to upstream (with your guidance how to | do this), as I believe it's per se correct and worth having there to not | need to carry a delta. Let's plan on this. I'll build a gsl package, let's see how it does and we can then propose this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
