this is an upstream bug https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4439 http://bugs.archlinux.org/task/18061 but it still leaves current wireshark-1.2.6 inoperable when compiled with zlib-1.2.4 solution might be to disable the zlib USE flag temporarily Reproducible: Always Steps to Reproduce: 1.USE="zlib" emerge =wireshark-1.2.6 2. 3.
Quite possible this is problem with zlib not wireshark. Currently I've updated deps and still it's better hold zlib-1.2.4 stabilization until we get some clarifications on this issue.
(In reply to comment #1) > Quite possible this is problem with zlib not wireshark. Currently I've updated > deps and still it's better hold zlib-1.2.4 stabilization until we get some > clarifications on this issue. > Then add -r1 with non-restricted depend to ~arch or package.mask wireshark. You can't introduce "down/up grade" cycle of that kind to tree.
+*wireshark-1.2.6-r1 (26 Mar 2010) + + 26 Mar 2010; Samuli Suominen <ssuominen@gentoo.org> + +wireshark-1.2.6-r1.ebuild: + Revision bump to -r1 preventing zlib downgrade for ~arch users wrt + #311241.
The following is not an issue to be fixed by Gentoo devs, but rather a comment for those who downgraded zlib due to this issue, and stumble upon this report. (In reply to comment #2) > You can't introduce "down/up grade" cycle of that kind to tree. Yes, downgrading libz can have consequences like this: Linking CXX executable kmplayer /usr/bin/cmake: /lib/libz.so.1: no version information available /usr/lib64/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3' /usr/lib64/libxml2.so.2: undefined reference to `gzdirect@ZLIB_1.2.2.3' Nothing a rebuild of packages depending on libz (libxml2 in this case) won't fix, but a thing to be considered nevertheless.
my reading of the bug is that there is nothing wrong with zlib-1.2.4, so CC->gone no package should ever force downgrade of libraries in the same stabilization state since it can easily break other things (as noted). i'll over look the pure stable state since people shouldnt be mixing anyways ...
zlib was disabled in -r1. Keeping this bug open until issue will be resolved.
(In reply to comment #6) > zlib was disabled in -r1. Keeping this bug open until issue will be resolved. > zlib-1.2.4.1 should solve this problem according to: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4606
Per comment #7 and link this is zlib bug. CC'ing base-system back so you were aware about issue and dropped 1.2.4 from the tree as soon as 1.2.4.1 will be released.
we're tracking the new version per another bug, so hopefully it'll be out soon
zlib-1.2.5 now in the tree
And I've put zlib USE flag back in wireshark 1.2.7. Please, test.