Michael Cohen wrote:
>Hi ULFL,
> Yeah, I appreciate that the ethereal developers have lots more
> important work to do. Ethereal is a great software!!!
>
>
:-)
> Would it be worth fixing the build problems first, and then tackling
> problems as they arise.
>
Well, that's the usual way things done in Ethereal, someone needs
something and tries to implement it ...
>For example you mention that libethereal does
> not support having multiple instances of everything. Do you mean that
> libethereal is not multi-threaded? or that all dissection trees share
> common static memory?
>
>
Multiple instances of everything, I'm not quite sure how this problem
will show up, you have been warned ;-)
What I know is that a lot of dissectors will use global memory,
fortunately most of these global vars are written at protocol
registration only.
As Guy Harris noted some time ago: "libethereal is a library that show
it's roots", no one tried this before so there might be other hidden
problems.
I don't want to discourage you, and would like to see a better library
support happen ...
> We could say that libethereal is not multi-threaded at this stage,
> and then fix bugs as they are found in static memory allocation.
>
> I think I have a way to work around the build deficiencies, but it is
> an ugly hack (tm). I can do an ldd on the ethereal/tethereal binary
> and just link all those libraries into my binary as well.
>
> Would it be worth having a look at the libethereal build process to
> see if I can easily fix this for inclusion into cvs?
>
>
As I don't know very well the unix way things build (I'm usually using
Win32 to build), I won't be much help here.
BTW: You didn't mention the application you want to write. Even if you
use libethereal only, this will still fall under the GPL license and
nothing else.
Regards, ULFL