Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] shared libraries

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Mon, 19 Mar 2001 20:56:32 -0800
On Mon, Mar 19, 2001 at 11:41:59PM -0500, Ed Warnicke wrote:
> The dependency on register.h is a little more basic, as it 
> speaks to how we handle dissectors.  I've considered a number of 
> possible ways around this problem.  
> 
> 1)	Convert the existing dissector base into individual plugins.  
> 	
> 	This has the advantage of being highly 
> 	modular.  It has the disadvantage that we are likely
> 	to run into some unhappy dependency issues that will have 
> 	to be resolved along the way, it will be a fair bit of 
> 	work, and that in almost any large undertaking there 
> 	is the risk of unpleasant unforseen consequences.

It also has the disadvantage that, unless you can build a version of
Ethereal where they're *not* plugins, it will be impossible, on many
platforms (possibly all platforms), to build a
completely statically linked version of Ethereal, because completely
statically linked programs, at least on Solaris (and I suspect on other
UNIX systems with shared library mechanisms influenced by that of SunOS
4.x - which includes, I think, {Free,Net,Open}BSD, and all systems with
Linux 2.x kernels and glibc, as well as SVR4 derivatives other than
Solaris), don't use the run-time linker at all, and thus don't have the
run-time linker's functionality available to them, and thus don't have
the ability to load code at run-time with "g_module_open()".

Now, I'm not sure there are any cases where you truly need a
*completely* statically linked version of Ethereal - if the problem is
that you don't want to have to install, for example, GTK+ and GLib
shared libraries on all machines, what you really want is something
statically linked with *those* libraries, not with the system libraries
as well.

Unfortunately, I don't know if it's particularly easy to set up the
configure script to put the "link statically" and "link dynamically"
flags into the right places in the linker command line so that you only
link selected libraries statically.  (You could, of course, do the build
on a machine where the *only* versions of the libraries in question are
static....)