On Jun 27, 2016, at 10:56 PM, Yang Luo <hslu...@gmail.com> wrote:
> Because of libpcap has exported the a data structure called eproto_db
> (https://github.com/the-tcpdump-group/libpcap/blob/master/nametoaddr.c#L320),
> when I compiled WinDump in MSVC specifying "wpcap.dll" as a delay loaded DLL,
> I encountered the link error 1194. The cause is here:
> https://msdn.microsoft.com/en-us/library/w59k653y%28v=vs.80%29.aspx?f=255&MSPPError=-2147217396.
>
> Delay loading wpcap.dll is an important part for the switch between Npcap
> mode and WinPcap mode. And from the comment, it seems that exporting this
> data is not very critical. So can we remove the "PCAP_API_DEF" at the line
> beginning to disable the exporting?
What the comment says is
* tcpdump used to import this, and it's declared as an export on
* Debian, at least, so make it a public symbol, even though we
* don't officially export it by declaring it in a header file.
which means that if we stop exporting it on UN*X, Debian might have to deem
that an incompatible change to the ABI and that might cause significant
disruption on Debian and its derivatives.
Other UN*Xes that ship libpcap might have a problem, especially if they have to
support third-party closed-source binaries.
So, at minimum, we should continue to export it on UN*X.
And that might be an issue with Windows binaries as well; I suspect WinDump,
for example, imports eproto_db from WinPcap, as it's based on an older version
of tcpdump that imported it from libpcap. I'll leave it up to you to determine
whether introducing a possible binary incompatibility between WinPcap and Npcap
is an issue.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
