Ulf Lamping wrote:
Hi List!
The current way we handle Win32 DLL export of symbols is a bit odd in my eyes.
You'll have to add the symbol name to a .def file. If it is a variable, in addition to this you'll need to append DATA to this entry and add WS_VAR_IMPORT to the corresponding header file.
A cleaner way seems to be using the __declspec(dllimport / dllexport) definitions "the right way", as MS itself promotes it e.g. in: http://msdn2.microsoft.com/fr-fr/library/8fskxacy(VS.71).aspx
The "trick" is to add something like:
#ifdef _EXPORTING
#define WS_SYMBOL_IMEXPORT __declspec(dllexport)
#else
#define WS_SYMBOL_IMEXPORT __declspec(dllimport)
#endif
to config.h.win32 - as _EXPORTING is automatically set by the compiler - and a corresponding dummy entry "#define WS_SYMBOL_IMEXPORT" to the automake config file so we dont get compiler errors on UNIX builds.
This way you'll simply add WS_SYMBOL_IMEXPORT to the header file to im/export a symbol, e.g.:
WS_SYMBOL_IMEXPORT int eth_stdio_open (...
... and your done! Ive tried this successfully with function names, DATA symbols should also work the same way.
Hi!
After some more experiments, I found a serious problem with this
approach, rendering it useless for us.
In epan we have files that both will import symbols from the wiretap.dll
and also export symbols to the outside with libwireshark.dll.
It's obvious that the same file cannot - at the same time - having
_EXPORTING defined and not defined.
We could so some strange #define #ifdef logic to prevent this problem,
but in the end I guess it is just better to keep our current .def file
approach.
So in the end "/Much Ado about Nothing/", taking me several hours of
work :-(((
Regards, ULFL