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 ___________________________________________________________________________ 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
