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