Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 8494] wireshark 1.9.1 configure script should have a --with-libnl option

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 9 on bug 8494 from Guy Harris

(In reply to comment #3)
> > 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 intend to be very careful by writing my own damn code to talk directly to
netlink sockets and completely avoiding libhell^Wlibel^Wlibnl entirely.  That
has the advantages of

    1) not having to care every time the libnl people decide to introduce a
New! Improved! API;

    2) not having distributions shipping versions of libpcap that aren't linked
with libnl, and thus not handling monitor mode as well as Wireshark users would
like, because it's just too much of a pain:

        http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651783

    3) completely eliminating the "libpcap is linked with libnlN and
application XXX using libpcap is linked with libnlM" application.

> > 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.

I read the downstream bug - and commented on it - before adding my comments to
this bug.  I have *NO* idea why the Mac user was trying to build libnl - a
pointless thing to do on any OS on which "uname -s | egrep Linux" doesn't print
anything.  I saw some references to "ebuild", and some Googling for

    ebuild "os x"

found some indications that there are versions of ebuild for OS X and, I guess,
other non-Gentoo OSes.  Perhaps he was using ebuild rather than just
downloading the source tarball, running the "macosx-setup.sh" script or
manually installing the dependencies and optional libraries, and doing the
usual configure/make/make install dance, in which case this is a problem with
ebuild, not with Wireshark - if ebuild can't understand that building program
XXX with library YYY gives it useful additional capabilities on Linux but not
only adds no capabilities on OS ZZZ but isn't even *possible* on OS ZZZ and
library YYY is a Linux-specific library, it's not a very good tool for building
software on anything other than Linux.

> > "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.

That's a bogus phrase.  The build process does not "depend" on the presence of
a library if the configure script checks for its presence, uses it if it's
present, and just disables code using it if it's not present.

Perhaps in ebuild it's listed as a "dependency" in the sense of "if you try to
build Wireshark, we will try to build and install libnl first", and it's listed
as a dependency on *all* platforms, but that's not our fault, that's the fault
of whoever packaged it.

> 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.

The autoconf macro that adds a --enable-XXX option also adds the --disable-XXX
option.  However, a --with-XXX option would be more appropriate here - and the
macro that adds a --with-XXX option also adds the corresponding --without-XXX
option.

The proper behavior here would be:

   if no option is given, check for libnl, and configure with it if present;

   if --with-libnl is given, check for libnl, and fail if not present;

   if --without-libnl is given, don't bother checking for libel, just configure
without it.

That's what's used for a number of other --with-XXX options.

However, given the version hell of libnl, perhaps --with-libnl should take an
argument that lets you specify that a particular version of libnl should be
used, with the default behavior being "use whichever version is the newest".

(Either that, or have Wireshark talk directly to netlink sockets.)

---

      You are receiving this mail because:

• You are watching all bug changes.