Bruce, Joseph R (Joe) wrote:
On 4/25/11 11:17 AM, "Jeff Morriss" <jeff.morriss.ws@xxxxxxxxx> wrote:
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.
Sorry, you're right; shared, not static. How much code would have to go
into that shared library? Do you have a rough idea of the amount of
effort to pull that off?
What's another solution? Compile my handler straight into the wireshark
executable? Build my plugin as a static library and link it in?
[Oops, I started writing this the other day but apparently forgot to
send it...]
My guess is that building your code straight into Wireshark is probably
the best way to proceed: what you're trying to do is not what plugins or
dissectors normally do.
