Re: Fwd: New datasource implementation

[Guy Harris <guy () alum mit edu>]

On Dec 20, 2011, at 4:37 PM, Akos Vandra wrote:

> When building wireshark based on the new libpcap with my module using
> libusb-1.0, it didn't build, because it was missing symbols
> (naturally, as wireshark didn't know it has to link libusb-1.0 as
> well). So insted of digging into where I have to add them, it seemed
> simpler to write a script.
> Also it seems unnatural that only for my project wireshark, and any
> other project using libpcap must use libusb-1.0...

"Use" in what sense?

On all modern UN*Xes, as far as I know, a dynamic library can be linked with another dynamic library, and if a program 
is explicitly linked with the first of those libraries, but *not* explicitly linked with the second of those libraries, 
the program will still work - the run-time linker will see that the first library requires the second library and will 
load and bind it in at run-time.

Only if the program is explicitly linked with a *static* version of the first library, or if it's being linked with a 
dynamic version of the first library that wasn't explicitly linked with a dynamic version of the second library, does 
it also need to be linked with a static version of the second library.

> I'm not quite sure I understand this. How would ./configure know that
> that the libusb_claim_interface is in the libusb-1.0 library?
> I'm sorry if I'm a bit slow here, I'm quite unfamiliar with autobuild
> and autoconf, should look into them soon.

It's unfortunately not trivial to do this, but it is possible.

If libpcap should, by default, support your new device if libusb is available on your machine (which, for most Linux 
distributions, means the "development" package for libusb must be installed on the machine on which you're building 
libpcap), with a "--disable-{whatever}" option available to let the user configure libpcap *not* to support your new 
device, I'd look at, for example, the code in configure.in for Bluetooth capturing - look for "enable Bluetooth 
support."  It lets you configure:

        with no options, in which case it'll look for the bluetooth.h header and include Bluetooth support if and only 
if it's present;

        with --disable-bluetooth, in which case it will leave the Bluetooth support out, even if the header is there.

If all versions of libusb have all the routines you need, checking for a header file for libusb is sufficient.  
(Checking for the *library* is not sufficient; this probably being Linux, you might have the libusb package installed, 
so that you have a dynamic library for the benefit of programs built with that library, but *not* have the libusb-dev 
package installed, so you don't have the header files needed in order to build code that uses libusb.)

If not all versions of libusb have those routines, you'll have to use a macro such as AC_CHECK_LIB to see whether 
libusb exists and has the function or functions in question.

> Is there a how-to guide to how to add a new module to libpcap?

Unfortunately, no.  The mechanisms for doing so were originally created as somewhat specialized hacks, and have been 
slowly turning into less-specialized mechanisms, but it's still not as clean as arguably should be the case.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.