| Summary: | app-admin/syslog-ng potentially links to libnsl but this relationship is undeclared | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | kfm <kfm> |
| Component: | Current packages | Assignee: | Tomáš Mózes <hydrapolic> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info | ||
|
Description
kfm
2019-04-06 02:17:17 UTC
Thanks, I'll check. The code in syslog-ng handling -lnsl has been there for 11 years: https://github.com/balabit/syslog-ng/blame/master/configure.ac#L756. However, libnsl used to be part of glibc and now is provided by net-libs/libnsl (https://archives.gentoo.org/gentoo-dev/message/034dbef0c206eba696c47c4daf2c7ce8). I think syslog-ng should provide and options to enable/disable libnsl support and we should mimic that option in the ebuild too. I ran a set of tests but cannot reproduce this behavior. I tried installing libnsl, then syslog-ng-3.20.1, then checked all binaries/libs with ldd. Nothing seems to link to libnsl. Please attach your $(emerge --info app-admin/syslog-ng). Did you experience runtime failures after removing libnsl? Can you provide that output please? Do you know a specific binary/library being linked to libnsl? Thanks Firstly, my effective USE flags for app-admin/syslog-ng are exactly as follows: caps http ipv6 json libressl python_targets_python3_6 Here is a transcript that demonstrates the problem on my build host, slightly edited for reasons of legibility. Note that I qualify syslog-ng by way of the gentoo repository because, since filing this bug, I committed a version to my repo that addresses the issue by making libnsl an unconditional dependency. # qlist -Iv libnsl net-libs/libnsl-1.2.0 # emerge -q1 syslog-ng::gentoo >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/syslog-ng-3.20.1::gentoo # scanelf -F '%F %n' $(qlist syslog-ng) | awk '$2 ~ /libnsl/ { print $1 }' /usr/lib64/syslog-ng/libexamples.so /usr/lib64/syslog-ng/libhook-commands.so /usr/lib64/syslog-ng/libappmodel.so /usr/lib64/syslog-ng/libxml.so /usr/lib64/syslog-ng/libtags-parser.so /usr/lib64/syslog-ng/libsnmptrapd-parser.so /usr/lib64/syslog-ng/libstardate.so /usr/lib64/syslog-ng/libmap-value-pairs.so /usr/lib64/syslog-ng/libtfgetent.so /usr/lib64/syslog-ng/libadd-contextual-data.so /usr/lib64/syslog-ng/libdisk-buffer.so /usr/lib64/syslog-ng/libcef.so /usr/lib64/syslog-ng/libdate.so /usr/lib64/syslog-ng/libkvformat.so /usr/lib64/syslog-ng/libgraphite.so /usr/lib64/syslog-ng/libpseudofile.so /usr/lib64/syslog-ng/libafstomp.so /usr/lib64/syslog-ng/libjson-plugin.so /usr/lib64/syslog-ng/libdbparser.so /usr/lib64/syslog-ng/libcryptofuncs.so /usr/lib64/syslog-ng/libbasicfuncs.so /usr/lib64/syslog-ng/liblinux-kmsg-format.so /usr/lib64/syslog-ng/libsystem-source.so /usr/lib64/syslog-ng/libconfgen.so /usr/lib64/syslog-ng/libcsvparser.so /usr/lib64/syslog-ng/libhttp.so /usr/lib64/syslog-ng/libafuser.so /usr/lib64/syslog-ng/libafprog.so /usr/lib64/syslog-ng/libaffile.so /usr/lib64/syslog-ng/libafsocket.so /usr/lib64/syslog-ng/libsyslogformat.so /usr/lib64/syslog-ng/loggen/libloggen_ssl_plugin.so /usr/lib64/syslog-ng/loggen/libloggen_socket_plugin.so /usr/lib64/libloggen_plugin.so /usr/lib64/libloggen_plugin-3.20.so.0 /usr/lib64/libloggen_plugin-3.20.so.0.0.0 /usr/lib64/libloggen_helper.so /usr/lib64/libloggen_helper-3.20.so.0 /usr/lib64/libloggen_helper-3.20.so.0.0.0 /usr/lib64/libsyslog-ng.so /usr/lib64/libsyslog-ng-3.20.so.0 /usr/lib64/libsyslog-ng-3.20.so.0.0.0 # emerge -acv libnsl # note that syslog-ng is not listed as a reverse dep ... Calculating dependencies... done! net-libs/libnsl-1.2.0 pulled in by: app-text/opensp-1.5.2-r3 requires net-libs/libnsl:0/2=, net-libs/libnsl:0= # emerge -C libnsl # note the preserved libs warnings for files owned by syslog-ng ... net-libs/libnsl selected: 1.2.0 protected: none omitted: none All selected packages: =net-libs/libnsl-1.2.0 >>> Unmerging (1 of 1) net-libs/libnsl-1.2.0... !!! existing preserved libs: >>> package: net-libs/libnsl-1.2.0 * - /usr/lib64/libnsl.so.2 * - /usr/lib64/libnsl.so.2.0.0 * used by /usr/lib64/libloggen_helper-3.20.so.0.0.0 (app-admin/syslog-ng-3.20.1) * used by /usr/lib64/libloggen_plugin-3.20.so.0.0.0 (app-admin/syslog-ng-3.20.1) * used by /usr/lib64/libosp.so.5.0.0 (app-text/opensp-1.5.2-r3) * used by 34 other files # emerge -1 syslog-ng::gentoo # now let's build without libnsl present ... # scanelf -F '%F %n' $(qlist syslog-ng) | awk '$2 ~ /libnsl/ { print $1 }' | wc -l 0 Created attachment 572830 [details]
emerge --info
Also, yes, I experienced a runtime failure by way of scenario "b", as described by my original report. The resulting error should come as no surprise:- # syslog-ng syslog-ng: error while loading shared libraries: libnsl.so.2: cannot open shared object file: No such file or directory Obviously, it's much harder to make syslog-ng break wherever it is built, owing to the unlink protection afforded by the preserved-rebuild mechanism. (In reply to Tomáš Mózes from comment #2) > The code in syslog-ng handling -lnsl has been there for 11 years: > https://github.com/balabit/syslog-ng/blame/master/configure.ac#L756. > However, libnsl used to be part of glibc and now is provided by > net-libs/libnsl If that is the case, then, > I think syslog-ng should provide and options to enable/disable libnsl > support and we should mimic that option in the ebuild too. syslog-ng should just depend on net-libs/libnsl until such a switch is available. (In reply to Andreas Sturmlechner from comment #7) > (In reply to Tomáš Mózes from comment #2) > > The code in syslog-ng handling -lnsl has been there for 11 years: > > https://github.com/balabit/syslog-ng/blame/master/configure.ac#L756. > > However, libnsl used to be part of glibc and now is provided by > > net-libs/libnsl > If that is the case, then, It was my hypothesis, but I cannot reproduce it. I tried installing libnsl, then emerging syslog-ng with almost same USE flags as Kerin (except for libressl), but after removing libnsl, syslog-ng works fine and I cannot see the error Kerin is experiencing :( > > > I think syslog-ng should provide and options to enable/disable libnsl > > support and we should mimic that option in the ebuild too. > > syslog-ng should just depend on net-libs/libnsl until such a switch is > available. I'll test with libressl if I can reproduce it. I tried to reproduce the issue from a chroot based on the stage3-amd64-hardened-20190501T214502Z tarball but haven't been able to so far. Here's what does _not_ trigger it: * upgrading to the equivalent 17.1 profile * keeping the 17.0 profile and switching from openssl to libressl-2.8.3 That's with net-libs/libnsl installed, of course. I have no leads at this point, but will post again if the situation changes. Here's an additional discrepancy between the (affected) host and the (unaffected) chroot.
# diff -u unaffected affected
--- unaffected 2019-05-07 02:02:01.395776560 +0200
+++ affected 2019-05-07 02:02:08.154735688 +0200
@@ -1,5 +1,7 @@
libsyslog-ng.so => /usr/lib64/libsyslog-ng.so (interpreter => none)
librt.so.1 => /lib64/librt.so.1
+ libnsl.so.2 => /usr/lib64/libnsl.so.2
+ libtirpc.so.3 => /lib64/libtirpc.so.3
libevtlog-3.20.so.0 => /usr/lib64/libevtlog-3.20.so.0
libcap.so.2 => /lib64/libcap.so.2
libpcre.so.1 => /lib64/libpcre.so.1
@@ -10,6 +12,7 @@
libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
libssl.so.46 => /usr/lib64/libssl.so.46
+ libresolv.so.2 => /lib64/libresolv.so.2
libcrypto.so.44 => /usr/lib64/libcrypto.so.44
libpthread.so.0 => /lib64/libpthread.so.0
libc.so.6 => /lib64/libc.so.6
It's curious that libssl.so.46 links to libresolv.so.2 in one instance, but not the other. Both have dev-libs/libressl-2.8.3 installed. I rebuilt the host's libressl and found that the discrepancy persists. That bothers me, but I don't know whether it pertains to this bug.
What do we do with this? I failed to reproduce this, there seems to be no more reports like this. Ignore it. I'm now able to reproduce this issue with another (unrelated) Gentoo host. The second build is with libnsl installed ... --- build.log.1 2019-07-18 01:16:27.423167886 +0100 +++ build.log.2 2019-07-18 01:13:49.482667712 +0100 @@ -183,7 +183,7 @@ checking for door_create in -ldoor... no checking for socket in -lsocket... no checking for nanosleep in -lrt... yes -checking for gethostbyname in -lnsl... no +checking for gethostbyname in -lnsl... yes checking for regexec in -lregex... no checking for res_init in -lresolv... no checking for strdup... yes (In reply to Kerin Millar from comment #13) > I'm now able to reproduce this issue with another (unrelated) Gentoo host. > The second build is with libnsl installed ... > > --- build.log.1 2019-07-18 01:16:27.423167886 +0100 > +++ build.log.2 2019-07-18 01:13:49.482667712 +0100 > @@ -183,7 +183,7 @@ > checking for door_create in -ldoor... no > checking for socket in -lsocket... no > checking for nanosleep in -lrt... yes > -checking for gethostbyname in -lnsl... no > +checking for gethostbyname in -lnsl... yes > checking for regexec in -lregex... no > checking for res_init in -lresolv... no > checking for strdup... yes Can you please reproduce on a fresh system? I wasn't able to reproduce this on an existing nor new system :( Hi Tomáš. I'm trying my best to arrange a set of circumstances that will allow you to reproduce the issue. I'm just as frustrated as you are that it is proving so difficult. If I don't make any further progress soon, I might try to obtain an opinion from upstream. In the meantime, it seems clear that the intent of the relevant configure test is to link against libnsl where possible. Perhaps the question here is not one of why it links to libnsl, but why it doesn't always link to libnsl. I'm closing for now as there is no way to safely reproduce this issue. If it happens again, please reopen. Thank you. |
