Michael Cohen wrote:
>Hi List,
> I am trying to develop a build environment for compiling programs
> against libethereal outside from the ethereal source tree proper. This
> is so that people can compile directly against their distributions
> /usr/lib/ethereal/libethereal.... shared objects.
>
> The first problem, of course is that there is no ethereal-dev package
> with relevant .h files. This can be solved by distributing the .h
> files with my application, and hoping that prototypes for the
> functions im using dont change too much between releases.
>
> The main problem I am having is that libethereal is not linked with
> the libraries which it needs, rather counting on ethereal to link
> them.
>
> This means that libethereal itself contains symbols which it needs to
> import from the linked in executable!!! Not only do I need to link
> into libethereal, but my binary needs to link into all those libraries
> which libethereal needs itself.
>
> Those libraries are obviously set through configure time, so I am
> unable to predict this list in a generic way.
>
> For example, libethereal imports the symbol adns_finish, but doing an
> ldd libethereal.so.0 does not reveal libadns, only by ldd
> /usr/bin/ethereal we see /usr/lib/libadns.so.1 is imported. objdump
> indicates that /usr/bin/ethereal does not use any libadns symbols
> anyway, its just linked in to satisfy the libethereal requirements.
>
> Is this a normal thing for a shared library to require libraries to be
> linked in by clients? should shared libraries themself be linked
> against those libraries they need - this will make them more self
> contained. So clients can link against libethereal without knowing or
> caring what libethereal really needs.
>
> I am working on debian testing with the standard ethereal package
> 0.10.10-2sarge2.
>
> Michael.
>
>
>
Hi Micheal.
libethereal in it's current state isn't meant to be used by other
programs than the Ethereal package itself, as this would require a lot
more effort.
The main purpose was to simply save code space as both ethereal and
tethereal uses a whole lot of identical code (that's how I
understand/remember it).
Someone else might correct me, but there are currently no attempts to
bring libethereal into a state where other programs (like your's) can
conveniently use libethereal. This would require more work, like making
it possible to keep multi instances of everything and ...
I do agree that this goal would be useful. But believe me, the Ethereal
developers have still a lot of other work to do ;-)
Regards, ULFL