BuildingAndInstalling

Please note: this page content is currently very limited. You may first consult the Ethereal User's Guide, the Ethereal Developers Guide and the various README files provided with Ethereal.

BuildingAndInstalling

OpenBSD 3.8

Here's a description of building Ethereal on OpenBSD 3.8 This may evolve into a real README.openbsd or something.

MacOS X 10.4 Intel & PowerPC

To build the package do:

Make sure /usr/local/bin is in the path as otherwise it wont find glib /gtk+ accordingly. Also you need glib/gtk+/libpcap to be built first. If you use fink or some other packaging system you probably can use glib2. for just ethereal installs, I would recommend glib 1.2 because it has no dependencies which are not already fulfilled by the operating system. Building version 2 will bring you to a long list of dependencies (you will become crazy if you try it...)

export CFLAGS="-O3 -fno-omit-frame-pointer"
export CXX="g++"
export CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti"
export LDFLAGS="-lstdc++ -liconv"
./configure --disable-gtk2 --disable-gtktest --disable-glibtest --enable-usr-local --enable-threads --disable-ssl --disable-dependency-tracking

You can build this way for Intel and for Power PC and use the lipo tool to merge both versions together to be a universal binary. Building for both architectures using -arch ppc -arch i386 doesnt work using the current Makefiles. While compiling for one architecture, the libraries /usr/local/lib/glib.a and /usr/local/lib/gmodule.a also have to exist only in this architecture and not as universal binary as the ethereal tool tries to use "ar" which can't really handle dual architecture files. Fix is to rename those files and extract the currently needed architecture with "lipo -thin"

If you don't have glib/gtk+ built those the following ways:

Get this version of GLIB [ ftp://ftp.gtk.org/pub/gtk/v1.2/glib-1.2.10.tar.gz ]

cp /usr/share/libtool/config.* .
mv gstrfuncs.c gstrfuncs.c.old
sed s/G_GNUC_PRETTY_FUNCTION//g < gstrfuncs.c.old > gstrfuncs.c
./configure --disable-shared --enable-static --mandir=/usr/share/man --disable-dependency-tracking

edit glibconfig.h and change the G_BYTE_ORDER definition to

#include <machine/endian.h>
#define G_BYTE_ORDER BYTE_ORDER

This will make sure it works properly on both architectures even when compiled on one for the other.

Get this version of GTK+ [ ftp://ftp.gtk.org/pub/gtk/v1.2/gtk+-1.2.10.tar.gz ]

cp /usr/share/libtool/config.* .
./configure --disable-shared --enable-static --mandir=/usr/local/man --with-glib-prefix=/usr/local --disable-dependency-tracking

Solaris

Pre-compiled packages are available from Sunfreeware.com. After downloading and extracting the files, you can install using the following commands:

pkgadd -d ethereal-0.10.7-sol8-sparc-local
pkgadd -d pcre-4.5-sol8-sparc-local
pkgadd -d glib-1.2.10-sol8-sparc-local
pkgadd -d gtk+-1.2.10-sol8-sparc-local
pkgadd -d libgcc-3.3-sol8-sparc-local
pkgadd -d libpcap-0.8.3-sol8-sparc-local

Although the pre-compiled packages from Sunfreeware.com are convenient, they are missing SNMP symbolic OID decoding which I find to be tremendously useful. To get this feature, you need to build Ethereal from source. As an example for Solaris 7, the following build environment is required:

pkgadd -d gcc-2.95.3-sol7-sparc-local
pkgadd -d glib-1.2.10-sol7-sparc-local
pkgadd -d grep-2.5-sol7-sparc-local
pkgadd -d gtk+-1.2.10-sol7-sparc-local
pkgadd -d gzip-1.3.5-sol7-sparc-local
pkgadd -d libgcc-3.3-sol7-sparc-local
pkgadd -d libpcap-0.8.3-sol7-sparc-local
pkgadd -d make-3.80-sol7-sparc-local
pkgadd -d net-snmp-5.1.1-sol7-sparc-local
pkgadd -d openssl-0.9.7d-sol7-sparc-local
pkgadd -d sed-4.1.1-sol7-sparc-local
pkgadd -d zlib-1.2.1-sol7-sparc-local

To compile the source code, enter the following commands with particular attention to the "configure" command.

PATH=/usr/local/bin:/usr/bin:/usr/sbin:/usr/ccs/bin
export PATH
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH
gunzip -c ethereal-0.10.7.tar.gz | tar xvf -
cd ethereal-0.10.7
./configure -disable-gtk2 -with-ssl=/usr/local/ssl
make

Finally, to install, use the standard "make install" as "root" with PATH and LD_LIBRARY_PATH as above.

Known Problems

Even though Ethereal doesn't use C++, if the compiler isn't installed, configure might issue these messages:

checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

with config.log containing:

configure:4981: /lib/cpp  conftest.cc
cpp: installation problem, cannot exec 'cc1plus': No such file or directory

This is due to a bug in libtool, fixed in version 1.5.10. The bug was introduced in version 1.5, and is not present in earlier versions.

If you fix the problem by installing a later version of libtool rather than a C++ compiler, be aware that it's not sufficient to install libtool in /usr/local, say, with $PATH set appropriately to override the older version in /usr. Libtool invokes the aclocal perl script, part of Automake, which hardwires the aclocal directory. E.g., if aclocal is installed in /usr/bin, it includes the line:

$acdir = '/usr/share/aclocal';

which means that /usr/share/aclocal/libtool.m4 is invoked instead of the latest version installed in /usr/local/share/aclocal/libtool.m4.

A simple way around this problem is to install Automake in /usr/local as well (or wherever you install libtool).

Discussion

I don't know if it's such a good idea to add another place which describes Build and Install. In addition, putting it at a very prominent place at the FrontPage and having next to no content, is a very bad idea in my eyes. - UlfLamping

Well, where is the other place? I did look and I've looked again, unsuccessfully. My thought in putting the link under Things not (yet) part of the User's Guide was, indeed, to follow the layout of the User's Guide. -- GraemeHewson

Well, we have the various README's, the User's Guide, the Developer's Guide ... - UlfLamping

What is the point of this wiki? Is it really a temporary repository, with all articles destined to be moved into the documentation distributed with Ethereal? -- GraemeHewson

Unfortunately, there's no current concept about this. However, at other pages I tried (at least) to link from the wiki the other interesting places, so the user get's at least an idea that there's other places he also might be interested to look at. There's a drawback in this, having too much links often gives the user a sense of being lost in a wiki

The main problem I have with this page is: the user gets to the FrontPage, finds: "oh, building and installing, I'll start there" jump to it and will be left with a nearly empty page with only a minor topic, but not explaining the main steps and no links to any other explanation. It seems this is all we have to say about bulding and installing of Ethereal!!!

There's another thing that's questioning here - where do you draw the line between the building and installing and the Development section? As it's getting more and more common today to use binary installers even on UNIX (yes, I know about Gentoo and a lot of others), I tend to drop these topics into the Development section.

So at least you should add links to all other interesting places regarding this topic. - UlfLamping

I'd say the front page "Building and Installing" page should be solely for those downloading an Ethereal source tarball and configuring, building, and installing it, as an alternative to downloading a binary package (either because they don't know about binary packages, or because the latest version isn't available in a binary package, or because binary packages aren't available for their OS, or because they prefer to build from source). I wouldn't use it for anything other than than - if somebody has Ethereal source and is building it because they're doing development work, any issues they might have should be dealt with under Development.

I'd also say what you do with the release tarball (i.e., configure/make/make install), and perhaps also link to the section of the main Web site for binary packages.

If we keep this page, I'd also put at least some of the items in the "Building Ethereal" section of the Ethereal FAQ here instead, in the "Known Problems" section. -Guy Harris

I don't mind -- I created this page just as a convenient place to put my comment about libtool, thinking others might expand it as they see fit. If the comment belongs in a README, so be it. -GraemeHewson

BuildingAndInstalling

User

Pages

Actions