Bruce, Joseph R (Joe) wrote:
Hi,
I'm writing a plugin that registers a capture file callback via
cf_callback_add (./file.c:173, ./file.h:83). The callback is invoked on
read and other interesting cf events. This works fine on my *nix build,
but Windows is unhappy. The only other code that registers a cf callback
is ./gtk/main.c, which Windows has no problem with. My plugin fails to
link with unresolved symbol errors:
link -dll /out:vulcan.dll /NOLOGO /INCREMENTAL:no /DEBUG
/MACHINE:x86 /SafeSEH /DYNAMICBASE /FIXED:no packet-vulcan.obj
vulcan_utils.obj plugin.obj ..\..\epan\libwireshark.lib
..\..\wsutil\libwsutil.lib C:\wireshark-win32-libs\gtk2\lib\glib-2.0.lib
C:\wireshark-win32-libs\gtk2\lib\gmodule-2.0.lib
C:\wireshark-win32-libs\gtk2\lib\gobject-2.0.lib vulcan.res
Creating library vulcan.lib and object vulcan.exp
packet-vulcan.obj : error LNK2019: unresolved external symbol
_cf_callback_add referenced in function _proto_register_vulcan
vulcan.dll : fatal error LNK1120: 1 unresolved externals
So one question I can't answer is why this works on the *nix side, and not
the Windows side.
I also can't answer why gtk (when building and linking libui.lib) succeeds
and my plugin fails to resolve cf_callback_add.
Finally, and this is most confusing to me, file.c is not even compiled
until wireshark.exe is built, which is much later in the build process
than my plugin and libui. How does that work?
libui is a static library (archive). Building one of those does not
require that all the symbols be resolved (which is a good thing: you
can't link an archive against another archive or shared libraries
anyway). It just means that when you finally link that library into an
executable (wireshark), you'll need to satisfy all the undefined symbols.
This also means, I think, that you can't use this routine in your
plugin--at least not in its present location.
