Summary: | net-analyzer/wireshark - major version upgrades link against old soname - wireshark: error while loading shared libraries: libwsutil.so.0: cannot open shared object file: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Peter Volkov (RETIRED) <pva> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | amade, enrico.tagliavini, netmon, stefanhetzwaantje, zerochaos |
Priority: | Normal | Keywords: | InVCS, UPSTREAM |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6011 https://bugs.gentoo.org/show_bug.cgi?id=422485 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | net-analyzer:wireshark-1.6.4:20111212-181454.log.gz [hppa,success] |
Description
Jeroen Roovers (RETIRED)
2011-12-12 20:02:52 UTC
Created attachment 295595 [details]
net-analyzer:wireshark-1.6.4:20111212-181454.log.gz [hppa,success]
Note of interest: this happened after an upgrade from 1.4.9 to 1.6.4, so it might be that only stable users are affected (i.e. not those using 1.6.2 right now). Hm, you must emerge -C wireshark, previous to upgrade and I think DEPEND="!!<net-analyzer/wireshark-1.6.0_rc1" should not allow you to upgrade. How did you manage to upgrade? (In reply to comment #3) > Hm, you must emerge -C wireshark, previous to upgrade and I think > DEPEND="!!<net-analyzer/wireshark-1.6.0_rc1" should not allow you to upgrade. > How did you manage to upgrade? Using --nodeps because the new ebuild was in the CVS check out, not in the rsynced tree. I see what you did there now, but are you sure there is no elegant solution? :) I've tried to find a more elegant way to resolve this issue, but it seems the way automake/libtool interact it's quite impossible to specify which SONAME of libwsutil should be used in install mode. *** Bug 394965 has been marked as a duplicate of this bug. *** *** Bug 395075 has been marked as a duplicate of this bug. *** *** Bug 423975 has been marked as a duplicate of this bug. *** For some reason, configure.in does a check "whether to use $prefix for headers and libraries" and then assumes that $prefix/lib is the place to go. However, this ignores the possibility we might rather use $prefix/lib64 or other nice goodies. Not only that, it goes on to add -L/usr/lib to LDFLAGS, which neatly plants it between our LDFLAGS and any linker arguments directing users to better places, so that even in src_install(), libtool relinks against the installed library. I have patched configure.in not to inject that bogus path and now a straight upgrade from 1.6.8 to 1.8.1-r1 seems to work fine. Please test and report back if this works for you too. But don't close it yet - we need to send this upstream too. (In reply to comment #9) > For some reason, configure.in does a check "whether to use $prefix for > headers and libraries" and then assumes that $prefix/lib is the place to go. > However, this ignores the possibility we might rather use $prefix/lib64 or > other nice goodies. Not only that, it goes on to add -L/usr/lib to LDFLAGS, > which neatly plants it between our LDFLAGS and any linker arguments > directing users to better places, so that even in src_install(), libtool > relinks against the installed library. > > I have patched configure.in not to inject that bogus path and now a straight > upgrade from 1.6.8 to 1.8.1-r1 seems to work fine. > > Please test and report back if this works for you too. But don't close it > yet - we need to send this upstream too. Love it, love it, love it. There are only two things I don't love about this patch, 1.) it's not in all the ebuilds in the tree yet and 2.) it's not upstream yet. Any part of that you would like me to help with? (In reply to comment #10) > (In reply to comment #9) > > For some reason, configure.in does a check "whether to use $prefix for > > headers and libraries" and then assumes that $prefix/lib is the place to go. > > However, this ignores the possibility we might rather use $prefix/lib64 or > > other nice goodies. Not only that, it goes on to add -L/usr/lib to LDFLAGS, > > which neatly plants it between our LDFLAGS and any linker arguments > > directing users to better places, so that even in src_install(), libtool > > relinks against the installed library. > > > > I have patched configure.in not to inject that bogus path and now a straight > > upgrade from 1.6.8 to 1.8.1-r1 seems to work fine. > > > > Please test and report back if this works for you too. But don't close it > > yet - we need to send this upstream too. > > Love it, love it, love it. There are only two things I don't love about this > patch, 1.) it's not in all the ebuilds in the tree yet and 2.) it's not > upstream yet. 2.) It's not accepted upstream (yet?) and there's a chance they won't accept it at all (certainly not as is) but then it's a tiny and simple patch to maintain in Gentoo. 1.) It applies against all versions in the tree, so I have renamed it to be more generally applicable (it's a QA violation in LDFLAGS, after all ;-) and use it in every ebuild except the obsolete 1.6.8. |