On Feb 21, 2013, at 2:15 AM, Romain Francoise <rfranco...@debian.org> wrote:
> Michael Richardson <m...@sandelman.ca> writes: > >> DISTRO MANAGERS: I think that the libusb should be disabled in libpcap, >> otherwise ELF shared library systems will break, as the application >> won't know to link libusb in. > > Hmm. It seems to me that pcap-config already does the right thing: > > % pcap-config --libs > -L/usr/lib/x86_64-linux-gnu -lpcap > % pcap-config --libs --static > -L/usr/lib/x86_64-linux-gnu -lpcap -lusb-1.0 -lpthread I assume he's saying that it should include -lusb-1.0 even without --static. However, as far as I know, if library X uses routines from library Y, and the shared version of X is linked with the shared version of Y when it's built, if a program links with library X but not with library Y, the program will still work, as the requirement for shared library Y is wired into the binary file for shared library X, and the run-time linker will load library Y when the program is started. Is that not the case? (I seem to remember testing it on one of my horde of Linux virtual machines, and found that it worked the way I thought it did.) >> What I'd like to see is a libpcap0.8 compatible libpcap1.4 release that >> has libusb removed. I'd like to also have a libpcap1.4 package that has >> libusb included. Would this make sense? > > As far as I can tell enabling libusb support doesn't actually change the > ABI, so you could have libusb support in libpcap0.8. But adding binary > dependencies to a core library has a cost that I'm not willing to pay > unless there are some compelling reasons... Guy and I had the same > discussion about libnl support a few months ago. Well, I think the right fix *there* is to have libpcap directly talk to a netlink socket - somebody's already filed a bug saying that libpcap should handle libnl3, so if they're up to *three different major versions* of the library so far, I give up.... _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
