> $ wireshark > wireshark: error while loading shared libraries: libz-ng.so.2: cannot open shared object file: No such file or directory > # emerge -av1g zlib-ng > [...] > $ wireshark # works
I remember seeing the zlib-ng bits in the build system diff but I was sure it was default off so I hadn't worried about it. I must have got it wrong. I'll take a look, thanks.
Note, I have used the wireshark from our binhost.
(In reply to Marcus from comment #2) > Note, I have used the wireshark from our binhost. I was curious what had happened here and this was the missing bit. :) Indeed: the binhost version of libwireshark.so.18.0.2 is built against zlib-ng (so it's not some accidental transitive dependency): $lddtree image/usr/lib64/libwireshark.so.18.0.2 | grep -A1 -B1 libz libwiretap.so.15 => /usr/lib64/libwiretap.so.15 libz.so.1 => /usr/lib64/libz.so.1 libcares.so.2 => /usr/lib64/libcares.so.2 -- libm.so.6 => /lib64/libm.so.6 libz-ng.so.2 => not found libzstd.so.1 => /usr/lib64/libzstd.so.1 libwsutil.so.16 => /usr/lib64/libwsutil.so.16 Looks like cmake added this when zlib-ng was found on the binhost: https://gitlab.com/wireshark/wireshark/-/blob/master/CMakeLists.txt#L1484 because it defaults to ON: https://gitlab.com/wireshark/wireshark/-/blob/master/CMakeOptions.txt#L89 So we either need an explicit ENABLE_ZLIBNG=OFF or add a USE for zlibng. Of course this raises the question whether this should continue to link against old zlib as well..?
Yes, if I then set “net-analyzer/wireshark” in world, emerge points to @preserved-rebuild. Unfortunately, I can't help you. But I would suggest to prefer an optional USE flag. Wireshark (still) works with the version in the tree.
(In reply to Holger Hoffstätte from comment #3) > So we either need an explicit ENABLE_ZLIBNG=OFF or add a USE for zlibng. > Of course this raises the question whether this should continue to link > against old zlib as well..? The wireshark cmake build first tries to find zlib-ng and only falls back to old zlib if -ng wasn't found. This is a good opportunity to discuss how we can/should handle zlib vs. zlib-ng in general. After thinking about this a bit more I don't think adding zlib-ng as USE is a good idea when the package can use -ng natively. It introduces ambiguity (what does it mean when both are set?) and fixes nothing. Simply using zlib as shortcut for zlib-ng should be enough in those cases. This would also ease transition (= no action required) when zlib-ng eventually becomes a system-wide option. I'll try and see if I can get this going and whether it uncovers any other pitfalls.
Created attachment 915986 [details, diff] Suggested changes for pure zlib-ng dependencies This turned out to be easier than expected; the attached patch (for discussion purposes only - no revbump etc.) shows that only a handful of changes were necessary. The wireshark binaries and libs are built purely against zlib-ng, and the only zlib-old dependency is transitively via Qt (which is fine). A headless wireshark on my server has no zlib-old dependency at all. \o/ I'll leave it to Sam to decide whether this is how we want to handle this and/or commit to -9999.
(In reply to Holger Hoffstätte from comment #5) > This would also ease transition (= no action required) when zlib-ng > eventually becomes a system-wide option. > (Still not convinced that's ever going to happen given their attitudes on compatibility.)
Suggestions for how to proceed: - we close 945994 since 4.2.9 is gone - 4.4.2 is already being stabilised in 945995, so to keep things simple and rebuild the broken binpkg (does this happen automagically?) we just make a direct-to-stable -r1 with explicit -DENABLE_ZLIBNG=OFF and clean up 4.4.1/4.4.2 - with the next release (4.4.3?) we add zlib-ng as USE=zlib preference & dependency - like outlined in my patch - I accept my fate and add myself as proxy-maint :-} OK?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=268938dd6737276136bb3773466bff0ba4d701b2 commit 268938dd6737276136bb3773466bff0ba4d701b2 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2025-01-07 17:46:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-07 18:53:35 +0000 net-analyzer/wireshark: avoid automagic zlib-ng dependency Explicitly disable zlib-ng to prevent an automagic dependency. zlib-ng is the preferred choice by upstream and will be enabled in future releases. Closes: https://bugs.gentoo.org/947293 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> net-analyzer/wireshark/wireshark-4.4.2-r1.ebuild | 344 +++++++++++++++++++++++ 1 file changed, 344 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a429b9703e75a47273ed5dc331819ea61efaa15 commit 9a429b9703e75a47273ed5dc331819ea61efaa15 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2025-01-07 17:51:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-07 18:53:37 +0000 net-analyzer/wireshark: prefer zlib-ng by default in live Upstream prefers zlib-ng to zlib and supports it natively. Bug: https://bugs.gentoo.org/947293 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Closes: https://github.com/gentoo/gentoo/pull/40029 Signed-off-by: Sam James <sam@gentoo.org> net-analyzer/wireshark/wireshark-9999.ebuild | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
