Wireshark-bugs: [Wireshark-bugs] [Bug 8494] wireshark 1.9.1 configure script should have a --wit
Comment # 3
on bug 8494
from Rick Zero_Chaos Farina
> As per the above, it's not that Wireshark has decided to stop using some
> feature from libpcap - it *still* will use the "turn on monitor mode" APIs
> in libpcap, which are the reason why *libpcap* currently uses libnl (and
> "the issues with that" are the reason why I *really* want to replace that
> libpcap code with code that directly talks to netlink sockets rather than
> having to deal with libnl1 and libnl2 and libnl3 and libnl3.1415926536...
> and libnl4 and libnl5 when they come out).
Please be VERY careful with this. I recently worked through a segfault that
turned out to be caused by kismet linking libnl3 and libpcap while libpcap was
(and still is) linking only to libnl1. This causes massive collisions of
functions afaict. Again, I'm not very good at this stuff, but pretty sure
causing libnl3 and libnl1 to be linked into the same binary is *bad*.
> If you're not building for Linux, the configure script isn't going to find
> libel, and will therefore not build with libnl, so this is not an issue for
> users who don't have Linux machines.
Except for the fact that this bug report originally came to us from a mac user
who was having configure errors. Please see downstream bug.
> "automagic dependency" appears to be an ebuild/Gentoo term.
"Automagic dependency" means specifically that it tries to detect something,
and links to it unconditionally if found. While I'm not certain if gentoo
coined the term (likely not honestly) I can say it affects all platforms as it
affects any build of the product which could be say, a debian build machine.
What happens if libnl just happens to be on the debian build machine? Then it
will be automagically linked to wireshark. What happens if libnl just happens
to not be on the build machine? Now the users get a different experience.
Please don't this this as a "gentoo" issue, this is a "failing to have
replicatable results on build" or even a "failing to do what the user expects
on build" issue.
It's not really a big deal, if you see the downstream bug there is already a
suggested patch, however, due to my own inexperience with autotools I'm waiting
on clarfication since the patch has --enable but I don't see an explicit
--disable option which is also needed afaict.
You are receiving this mail because:
- You are watching all bug changes.
