Wireshark-dev: Re: [Wireshark-dev] Using cf_callback_add from a plugin
From: "Bruce, Joseph R (Joe)" <joseph.bruce@xxxxxxx>
Date: Mon, 25 Apr 2011 10:38:03 -0700
>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?