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.