These patches are correct to the best of my knowlege / ability:
-
https://github.com/bukzor/s6-packaging/blob/dockerize/skalibs/debian/patches/01_link_against_librt_if_necessary.patch
-
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
On Wed, Aug 12, 2015 at 10:20 AM, Buck Evan <buck_at_yelp.com> wrote:
> I think the Right fix is to add -lskarnet to the requirments of
> execline.so and s6.so similar to what I've done.
> I was likely overzealous when I changed the .a requirements and should
> back that bit out.
>
> On Wed, Aug 12, 2015 at 10:18 AM, Buck Evan <buck_at_yelp.com> wrote:
>
>> Removing the s6 patch gives essentially the same issue:
>>
>> dpkg-shlibdeps: warning: symbol open_write used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol byte_chr used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol openreadnclose used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol uint16_pack_big used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol fd_close used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol fd_write used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol open_create used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol stralloc_catb used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol open_read used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol openwritenclose_suffix_internal used by
>> debian/s6/usr/lib/x86_64-linux-gnu/libs6.so.2.2.0.0 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: 43 other similar warnings have been skipped (use
>> -v to see them all)
>>
>>
>> This is the compilation line for libs6.so:
>>
>> exec gcc -o libs6.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/execline
>> -L/usr/lib/x86_64-linux-gnu -shared -Wl,-soname,libs6.so.2
>> src/libs6/ftrigr1_zero.lo src
>> /libs6/ftrigr_check.lo src/libs6/ftrigr_end.lo src/libs6/ftrigr_start.lo
>> src/libs6/ftrigr_startf.lo src/libs6/ftrigr_subscribe.lo
>> src/libs6/ftrigr_unsubscribe.lo s
>> rc/libs6/ftrigr_update.lo src/libs6/ftrigr_wait_and.lo
>> src/libs6/ftrigr_wait_or.lo src/libs6/ftrigr_zero.lo
>> src/libs6/ftrigw_clean.lo src/libs6/ftrigw_fifodir_make
>> .lo src/libs6/ftrigw_notify.lo src/libs6/ftrigw_notifyb.lo
>> src/libs6/ftrigw_notifyb_nosig.lo src/libs6/s6_accessrules_backend_cdb.lo
>> src/libs6/s6_accessrules_backe
>> nd_fs.lo src/libs6/s6_accessrules_keycheck_ip4.lo
>> src/libs6/s6_accessrules_keycheck_ip6.lo
>> src/libs6/s6_accessrules_keycheck_reversedns.lo src/libs6/s6_accessrules
>> _keycheck_uidgid.lo src/libs6/s6_accessrules_params_free.lo
>> src/libs6/s6_accessrules_uidgid_cdb.lo
>> src/libs6/s6_accessrules_uidgid_fs.lo src/libs6/s6_supervise_loc
>> k.lo src/libs6/s6_supervise_lock_mode.lo src/libs6/s6_svc_write.lo
>> src/libs6/s6_svc_writectl.lo src/libs6/s6_svstatus_pack.lo
>> src/libs6/s6_svstatus_read.lo src/lib
>> s6/s6_svstatus_unpack.lo src/libs6/s6_svstatus_write.lo
>> src/libs6/s6lock_acquire.lo src/libs6/s6lock_check.lo
>> src/libs6/s6lock_end.lo src/libs6/s6lock_release.lo s
>> rc/libs6/s6lock_start.lo src/libs6/s6lock_startf.lo
>> src/libs6/s6lock_update.lo src/libs6/s6lock_wait_and.lo
>> src/libs6/s6lock_wait_or.lo src/libs6/s6lock_zero.lo sr
>> c/libs6/s6_fdholder_delete.lo src/libs6/s6_fdholder_delete_async.lo
>> src/libs6/s6_fdholder_getdump.lo src/libs6/s6_fdholder_list.lo
>> src/libs6/s6_fdholder_list_async
>> .lo src/libs6/s6_fdholder_list_cb.lo src/libs6/s6_fdholder_retrieve.lo
>> src/libs6/s6_fdholder_retrieve_async.lo
>> src/libs6/s6_fdholder_retrieve_cb.lo src/libs6/s6_fd
>> holder_setdump.lo src/libs6/s6_fdholder_store.lo
>> src/libs6/s6_fdholder_store_async.lo
>>
>> On Wed, Aug 12, 2015 at 10:14 AM, Buck Evan <buck_at_yelp.com> wrote:
>>
>>> 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 <buck_at_yelp.com> 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 <
>>>> ska-skaware_at_skarnet.org> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Wed Aug 12 2015 - 18:12:06 UTC