This is the compilation line for libexecline.so exec gcc -o libexecline.so -std=c99 -fomit-frame-pointer -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-stack-protector -pipe -Wall -fPIC -Wl,--hash-style=both -L/usr/lib/skalibs -L/usr/lib/x86_64-linux-gnu -shared -Wl,-soname,libexecline.so.2 src/libexecline/el_execsequence.lo sr c/libexecline/el_getstrict.lo src/libexecline/el_parse.lo src/libexecline/el_parse_from_buffer.lo src/libexecline/el_parse_from_string.lo src/libexecline/el_popenv .lo src/libexecline/el_pushenv.lo src/libexecline/el_semicolon.lo src/libexecline/el_spawn0.lo src/libexecline/el_spawn1.lo src/libexecline/el_substandrun.lo src/l ibexecline/el_substandrun_str.lo src/libexecline/el_substitute.lo src/libexecline/el_transform.lo src/libexecline/el_vardupl.lo src/libexecline/exlsn_define.lo src /libexecline/exlsn_elglob.lo src/libexecline/exlsn_import.lo src/libexecline/exlsn_multidefine.lo src/libexecline/exlsn_exlp.lo src/libexecline/exlsn_main.lo src/l ibexecline/exlsn_free.lo src/libexecline/exlp.lo
I don't see -lskarnet. On Wed, Aug 12, 2015 at 10:12 AM, Buck Evan <[email protected]> wrote: > 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 >> >> >
