Ethereal-dev: RE: [ethereal-dev] Solution for Problems with nightly builds on F reeBSD 4.0
I have run into this multiple times in the past with lots of user compiled
packages on Slackware, Solaris and HP-UX (which I use) and with RedHat
(solving other people's problems).
The Gnuish install location is /usr/local. Slackware installs many of the
non-X11 packages to /usr and the X11 ones to /usr/X11R6. Solaris uses either
/usr/local or /opt/packagename. HP-UX uses /opt/packagename. RedHat does
different things.
If you want things to be seamless, you have to look where your package
manager put bits and build for the same location.
I have taken to creating packages and then upgrading the distributed
version. Most of the problems go away.
Regards,
Andrew Hood
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable. -- Leslie Lamport,
as quoted in CACM, June 1992
"Any views or opinions presented are solely those of the author and do not
necessarily represent those of the Westpac Banking Corporation."
-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxxxxx]
Sent: Tuesday, July 25, 2000 5:34 PM
To: Guy Harris
Cc: Tuexen Michael; 'ethereal-dev@xxxxxxxx'
Subject: Re: [ethereal-dev] Solution for Problems with nightly builds
on FreeBSD 4.0
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.
<<application/ms-tnef>>
