On 4/25/11 11:17 AM, "Jeff Morriss" <[email protected]> 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? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
