On Fri, Dec 17, 2010 at 03:40:55PM +0100, Balint Reczey wrote:
> 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.
And vice versa: symbols listed in headers should be exported.
> > 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.
I would argue that if a function is in a header file in epan or
epan/dissectors, it is part of the public API. Perhaps only headers in epan
and packet-*.h headers in epan/dissectors. It's not that every non-static
symbol should be exported, but that every symbol declared in a header file
is part of the public API and should therefore be exported.
> > 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.
Is this a newly-added linker flag?
> Cheers,
> Balint
--Greg
