On Tue, Sep 17, 2002 at 12:41:43PM -0700, Guy Harris wrote:
> libm routines - and temporarily arrange that there's no
> "/usr/lib/libm.so.2", and try to run the program, you get
>
> /usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found
>
> I suspect that's the behavior you'd get on most systems with a SunOS
> 4.x-derived shared library mechanism, e.g. the BSDs, Linux
> distributions, and Solaris and other SVR4-based systems. You might get
> it with other UNIX systems as well.
I don't think you are correct here: I've worked (well, acutally not :-)
with versions of emacs that run with or without X. What I *think*
they do is they load the required libx11 manually in case it is needed.
Things could be done that way.
On the original post: There are two ways to achieve better modularity:
A generic application that loads the appropriate front end on demand or
the other way round: Many specific front ends that load a set of common
libraries.
Both ways look interesting and both require a proper seperation of the
dissector, wiretap and front end code first. Except for a patch recently
sent dealing with files, there has been no work on that front for more
than a year. So as long as nobody takes up the work, musing about which
way is best is interesting but not improving Ethereal. That said: Once
I'm done with the current automake mess I intend to open a new branch
in cvs where I intend to make the dissector stuff into its own library.
After that, the places that need cleaning up will show up more
prominently :-)
Ciao
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.