Bruce, Joseph R (Joe) wrote:
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.
Okay, that makes sense. Thanks for explaining it.
This also means, I think, that you can't use this routine in your
plugin--at least not in its present location.
Does that mean if I compiled the routine into a static library that I link
into my plugin dll, and the wireshark executable of course, it would work?
Hmmm, that would mean the there would be 2 copies of that routine in the
final (running) process: one in the executable and one in the
(dlopen()'d) plugin. I'm not sure how that would work out... Maybe a
symbol collision?
The Correct solution would probably be to put the routine in a shared
library which both wireshark and the plugins are linked against.
