Am 18.12.2010 00:48, schrieb Gregory Seidman:
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.
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.
The problem I see is that Wireshark doesn't have "The API". It is not
obvious which header files, and which declaration are public. When you
look at the libwireshark.def it seems that definitions have been added
or removed just as the needs appeared.
For example in rev 34876 the function proto_item_append_string is added
to the exported functions. The header file proto.h that declares (and
documents) this function is not changed since rev 34466. So I can't
think of any reason to add this symbol to the export list than that
anybody was asking for it.
I would propose to _define_ the Wireshark API. This will be a process
and I don't expect this to become available in a few days. One way to
identify *the Wireshark API* would be to identify this API in the header
files.
With a central macro WIRESHARKAPI(or WSAPI
// config.h
#ifdef MSVC_VARIANT
// generating libwireshark.DLL
#ifdef _NEED_VAR_IMPORT
#define WIRESHARKAPI __declspec(dllimport)
#else
#define WIRESHARKAPI __declspec(dllexport)
#endif
#else
// not generating DLL
#define WIRESHARKAPI extern
#endif
you can define the API in the header files like this:
// proto.h
WIRESHARKAPI proto_tree* proto_tree_create_root(void);
WIRESHARKAPI proto_item *
proto_tree_add_item(proto_tree *tree, const int hfindex, tvbuff_t *tvb,
const gint start, gint length, const guint encoding);
The has some advantages
- one central place to define how the functions become part of the API
in config.h
- exactly one place of definition if a symbol is part of the API.
Currently you define the symbol in header and DEF file.
- It is visible immediately if a declaration in the header files is part
if the API or not.
What do you think about it?
--
Andy
