Removing the execline patch results in:
dh_shlibdeps -O--parallel -O--autodest dpkg-shlibdeps: warning: symbol waitpid_nointr used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol PROG used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol stralloc_catb used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol env_get2 used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol env_string used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol byte_chr used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol pathexec0_run used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol str_start used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol stralloc_free used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: symbol uint320_scan_base used by debian/execline/usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 found in none of the libraries dpkg-shlibdeps: warning: 18 other similar warnings have been skipped (use -v to see them all) The manpage <http://manpages.ubuntu.com/manpages/jaunty/man1/dpkg-shlibdeps.1.html> says: *symbol* *sym* *used* *by* *binary* *found* *in* *none* *of* *the* *libraries.* The indicated symbol has not been found in the libraries linked with the binary. The *binary* is most likely a library and it needs to be linked with an additional library during the build process (option *-l**library* of the linker). It's true that the execline.so doesn't link to skalibs.so even though it requires its symbols: $ ldd /usr/lib/x86_64-linux-gnu/libexecline.so.2.1.3.0 linux-vdso.so.1 (0x00007ffff2dfe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5dcf8c000) /lib64/ld-linux-x86-64.so.2 (0x00007ff5dd53f000) On Wed, Aug 12, 2015 at 3:05 AM, Laurent Bercot <[email protected]> wrote: > > (Please follow-up this part of the thread to the skaware mailing-list.) > > On 12/08/2015 08:37, Buck Evan wrote: > >> - >> >> https://github.com/bukzor/s6-packaging/blob/dockerize/execline/debian/patches/02_link_against_libskarnet.patch >> - >> >> https://github.com/bukzor/s6-packaging/blob/dockerize/s6/debian/patches/75_dot_so_link_skarlib.patch >> >> >> Again this is because the build derps without them, but I forget the exact >> failure mode. >> I'll track down details upon request. >> > > The parts for binaries and static libraries are clearly invalid. If > something breaks while building those, then there's a problem with the > way the build is invoked, or the options to configure. > For static libraries, -lskarnet is nonsense. For binaries, -lskarnet > is already listed in the requirements ($^) and should be translated > to a .a or .so by vpath resolution, so it is incorrect to list it > again. Something is definitely wrong if the package builds with them > while it won't build without. > > I'm still unsure about the shared libraries parts. I don't think > it should be needed, but my test suite isn't up to par and I need to > update it to test the problematic cases and understand exactly what > is happening. > > In the meantime, please find the problem with your build and fix it. > Chances are you won't need the shared libraries patch either once > you've done that. :) > > > It seems likely to me that you'll want to figure out and fix these two >> issues given your response to the above patch. >> Is that right? >> > > Yes, and now you have work to do too. :P > > -- > Laurent > >
