Ethereal-dev: Re: [ethereal-dev] Solution for Problems with nightly builds on FreeBSD 4.0

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Tue, 25 Jul 2000 00:34:21 -0700
On Fri, Jul 21, 2000 at 02:16:22PM -0700, Guy Harris wrote:
> In any case, we should perhaps throw a pile of "-I" flags when we run
> "aclocal" in "autogen.sh", to include every directory in which we have
> ever heard that some flavor of UNIX has decided to hide autoconf macros
> ("/usr/local/share/aclocal", "/usr/X11R6/share/aclocal", and every other
> directory that we stumble across).

I tried that - unfortunately (perhaps as a result of having installed
xmms as a binary package; it depends on GTK+, which was also installed
as a binary package), I have "/usr/X11R6/share/aclocal/gtk.m4" on my
machine, but, as I also have a GTK+ built from source installed, the
"-I /usr/X11R6/share/aclocal" flag causes *both* "gtk.m4" files to be
read, and aclocal whines about a whole bunch of duplications.

This is the sort of thing that makes me truly hate it when OSes come
with third-party libraries in the standard system directory or have
packages available to install them in the standard system directory -
you often end up with Dueling Libraries, with one copy in a system
directory and another copy under "/usr/local", and either

	1) have trouble trying to get configure scripts to use the
	   version you installed from source rather than the version
	   installed in a system directory (because you didn't tell the
	   library's configure script to jam stuff in the system
	   directory, so that the built-from-source copy overwrites the
	   copy in the system directory - which means that you may lose
	   the built-from-source copy if you install a new OS release or
	   install some program that depends on a later version of the
	   library than was installed in the system directory);

	2) have header files that don't match the libraries (which I
	   suspect causes problems when people misread

		http://ethereal.zing.org/faq.html#q3.4

	   and both install a new version of UCD SNMP from source *and*
	   try to build and install Ethereal from source; this may cause
	   the headers with which Ethereal is built to indicate that
	   "snmp_set_full_objid()" or "snmp_set_suffix_only()" is not a
	   macro, so that the source compiles to code that calls it as a
	   function, but causes Ethereal to be linked with the old
	   shared library, without "snmp_set_XXX" routines, because when
	   UCD SNMP was built and installed, it was built with
	   non-shared libraries as that was the default);

	3) cause the problem I just saw.