> Thanks I installed libtool 1.3.4. (1.3.3 did not work - rejected by
> version check).
I'm not sure that, as the stuff you added to the INSTALL file suggests,
it's needed if somebody's installed the distribution; I tried
"pseudo-uninstalling" "libtool" (by moving stuff into holding-tank
directories so that they're not where they should be and so that I can
move them back), building a distribution tarball, unpacking it, doing
"configure", and doing "make", and it seemed to work. "make install"
also worked.
However, as people who get source often want to do development work, we
should probably indicate *somewhere* that, to do development, you may
need "automake", "autoconf" 2.13 or later, and "libtool" 1.3.4 or later.
On the other hand, it appears that installing "libtool" caused "libldtl"
to be installed, so, if we *do* require that people installing the
distribution install "libtool" - or, if it's not installed, disable
plugins, just as we disable capture if we don't find "libpcap", disable
reading compressed files if we don't find "libz", and disable fancy SNMP
dissection in 0.8.0 if we don't find an SNMP library - we could probably
leave the "libltdl" source out of our distribution. This might solve
the problem you're seeing.
> The build still fails with the following. Not sure
> this is problem with libtool, or problem on ethereal.
That'd be a bit annoying to debug, as
1) it may be specific to NetBSD (I didn't see it on FreeBSD);
2) the Makefile cheerfully destroyed the evidence by removing
".libs/etherealS.o", so you'd have to tweak the Makefile by
hand not to do that - and I'm not sure where it does that.
> ./configure --disable-shared did not solve my problem. it raises
> other problem (plugins/gryphon/packet-gryphon.c actually defines
> proto_init() twice).
The problem there is that it's statically linking a plugin.
Dynamically-loaded-at-run-time files can have symbols with the same name
as symbols in the program that's loading them (avoiding having any such
symbols could be Very Difficult Indeed, as a new version of the program
or the plugin could add a new symbol, so even if you're avoiding it
*now* you may not avoid it in the future), but statically-loaded files
can't.
I suspect that if we build with "--disable-shared", we may want to
disable plugins; at least on some platforms, statically-linked programs
*cannot* use "dlopen()".
