Hi Gregory, On 12/17/2010 03:21 PM, Gregory Seidman wrote: > I keep running into this issue where I'm working on a dissector plugin (for > internal distribution, on Windows) and want to use some function declared > in a header file in epan or epan/dissectors only to discover that it won't > link. Even if I modify libwireshark.def in my source tree so the plugin > will link, it will fail to load in any other build of Wireshark (e.g. the > standard release). Symbols listed in libwireshark.def are the symbols provided for external use. We should not list symbols not exported from libwireshark in headers provided for plugin development, I agree.
> Why isn't libwireshark.def generated from all of those header files as part > of the build system? Is it just the difficulty of extracting those function > declarations, or is there some policy reason? Would there be any objection > to a patch (almost certainly including a Perl or Python script) to generate > it as part of the build? The point of having libwireshark.def (and libwireshark.sym from now) is to list the symbols we consider to be part of the public API (ABI). We can keep those symbols reasonably stable while we are free to change the internal symbols frequently. Please don't provide a patch for exporting all symbols, but name the symbol you miss from libwireshark.def. > Note that this is unique to Windows, as far as I know. Shared objects > (a.k.a. DLLs) under any *nix system I know of default to exporting all > (non-static) symbols. Windows DLLs, however, default to exporting no > symbols, and there are mechanisms both in the code (i.e. a keyword) and > outside the code (i.e. a .def file) to explicitly export individual > symbols. Exporting all symbols from .so files is a bad practice and we just stopped doing so in the development branch. Cheers, Balint ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
