I sure would rather do it that way, as libtool can be quite annoying at
times.
However, there is one concern, it does tie ethereal to glib/gtk. (Not that I
think this is bad.)
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Gilbert Ramirez [mailto:gram@xxxxxxxxxx]
> Sent: Wednesday, January 12, 2000 10:18 PM
> To: ethereal-dev@xxxxxxxx
> Subject: [ethereal-dev] Plugins and dynamic linking
>
>
> Well, I've gotten the current CVS image to compile on win32,
> with zlib, with snnmp, but without libpcap.
>
> (I haven't tested it... it just now finished compiling :-)
>
> I avoided the whole libltdl directory, which provides wrapper
> routines for dlopen() and friends. I instead used glib's
> g_module_*() routines (found in gmodule.h), since it is supposed
> to work on the major Unices *and* win32. That is, instead of
> seeing if libltdl would build and work on win32, I changed the plugin
> code to use g_module_*() and linked against the normal glib
> stuff. (and gmodule.lib/dll on win32)
>
> It was nice for me because I can easily download gmodule.dll
> for win32, and on Unix, everyone already has glib.so built before
> they try to build Ethereal. It's one less step for the Ethereal build.
> So, in theory, someone could make a gryphon.dll
> and load it as a plugin; I won't try it, since I'm not
> much of an win32 builder.
>
> I've tested the functionality of gmodule on Linux, and plugins
> still work. I'll provide a patch before I check in the changes,
> but at this point does anyone have any reason for not
> changing our dynamic linking routines to use gmodule?
>
> --gilbert
>
