[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

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.