On Thu, Oct 27, 2016 at 09:36:47PM -0700, Guy Harris wrote:
> On Oct 27, 2016, at 8:54 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> > On Oct 27, 2016, at 4:18 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> >
> >> (the policy 42 stuff fixes
> >> the symptom instead of the root cause).
> >
> > ...the policy 42 stuff. Apple doesn't build libpcap with an @rpath install_name, and we don't do so with autotools, so I'm not sure whether we want to do that.
>
> Actually, for that reason, we *do* want to set that policy to "OLD", so we don't get an @rpath install name and don't get suggestions from CMake that we should want it, so I checked that one in as well.
OK, after building libpcap with autotools to have an install target and fixing two
warnings turning errors in Wireshark I now have a "working" version with rpcap compiled
in (at least config.h has both HAVE_REMOTE and HAVE_PCAP_REMOTE) - it just fails
to pick up the newly compiled and installed version of libpcap and uses the system version
instead:
jmayer@newegg:~/worktmp/wireshark$ otool -L /usr/local/bin/Wireshark.app/Contents/MacOS/Wireshark
/usr/local/bin/Wireshark.app/Contents/MacOS/Wireshark:
...
/usr/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.0.0)
...
Wireshark itself was built using cmake.
Ideas how to fix this?
Thanks
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.