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?
What I'm looking to do is capture some metadata as users interact with the
loaded packets, so I don't care about tshark (to answer Guy's question).
I still don't understand why this code works on the *nix side, but not
Windows. Any ideas there?
