["Olivier Biot" <ethereal@xxxxxxxxxx>]

Hi list,

If I build Ethereal with plugins out-of-the-box, then the plugin
dissector linkage aborts because of unresolved symbols from
libethereal and sometimes from GLib, as can be seen in the libtool
link step below:

/bin/sh ../../libtool --mode=link
gcc  -D_U_="__attribute__((unused))" -Wall -W -Wcast-qual -Wcast-align
 -Wbad-function-cast -pedantic -Wstrict-prototypes -g -O2 -I/usr/local
/include -pthreads -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2
.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R
6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -no-u
ndefined -L/usr/local/lib -L/usr/local/lib -o acn.la -rpath
/usr/local/lib/ethereal/plugins/0.10.3 -module -avoid-version
packet-acn.lo
gcc -shared  .libs/packet-acn.o  -L/usr/local/lib  -o
.libs/acn.dll -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/acn.d
ll.a
Creating library file: .libs/acn.dll.a
.libs/packet-acn.o(.text+0x3c2): In function `dissect_sdt':
/home/Eigenaar/ethereal/cvs/ethereal-pcre/plugins/acn/packet-acn.c:232
: undefined reference to `_proto_tree_add_item'
.libs/packet-acn.o(.text+0x3f4):/home/Eigenaar/ethereal/cvs/ethereal-p
cre/plugins/acn/packet-acn.c:236: undefined reference to
`_proto_tree_add_item'
[and many similar warnings on the following lines]

However compilation ***succeeds*** when I (manually) append
"-L../../epan -lethereal" to the libtool link line, like in:
$ /bin/sh ../../libtool --mode=link
cc  -D_U_="__attribute__((unused))" -Wall -W -Wcast-qual -Wcast-align 
-Wbad-function-cast -pedantic -Wstrict-prototypes -g -O2 -I/usr/local/
include -pthreads -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.
0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6
/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include    -no-un
defined -L/usr/local/lib -L/usr/local/lib -o acn.la -rpath
/usr/local/lib/ethereal/plugins/0.10.3 -module -avoid-version
packet-acn.lo  -L../../epan -lethereal

This applies to *all* plugins.

The GIOP (2 shared objects), Gryphon, IRDA and MGCP plugins
additionally require linkage against GLIB_LIBS (in order to fulfill
the dependencies on g_log, g_free, g_mem_chunk_alloc, g_mem_chunk_new,
g_mem_chunk_destroy, g_hash_table_destroy, g_hash_table_lookup,
g_hash_table_insert).

If I now complete the compilation from the top level directory,
Ethereal compiles successfully!

If I run the compiled Ethereal, I see an empty plugin dissector list,
however. Is there a means to run the compiled-but-not-installed
Ethereal *with* the generated plugins?

If I do a "make install",  I see many occurrences of the following
message:
<start>
Libraries have been installed in:
   /usr/local/lib/ethereal/plugins/0.10.3

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
<end>
Is this message meaningful?

BTW the ***installed*** ethereal WORKS!!!

Finally, here's my question: is it OK that I add the following line to
all plugin's Makefile.am files?

    rudp_la_LIBADD = -L../../epan -lethereal @GLIB_LIBS@

(Here the Reliable UDP plugin dissector was taken as an example).

Will this still work on non-CygWin systems? For the UN*X users out
there compiling with plugins, could you test the following: add
"rudp_la_LIBADD = -L../../epan -lethereal @GLIB_LIBS@" to the
plugins/rudp/Makefile.am file just after the 2 other "rudp_la_XXX"
lines, do a make clean in the plugins/rudp directory, and then do a
make (automake will automagically be called so no need to rebuild
all). You can also test with a plugin dissector for which you have an
example capture, this way the plugin can be tested functionally too
(this way I tested the IRDA plugin).

Regards,

Olivier