Bryant, Stephanie wrote:
I have attached the top level "config.log"
It says
configure:24482: result: no
configure:24510: checking whether %llx can be used to format 64-bit integers
configure:24556: gcc -o conftest -D_U_="__attribute__((unused))" -g -O2
-Wall -W -Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
-I/usr/local/include -pthread -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/X11R6/include
-I$(top_builddir)/../glib-2.12.13/. -I$(top_builddir)/../glib-2.12.13
-I$(top_builddir)/../glib-2.12.13/./gmodule
-I$(top_builddir)/../glib-2.12.13/./glib
-I$(top_builddir)/../pango-1.16.4/. -I/usr/local/include/gtk-2.0
-I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0
-I/usr/local/include/cairo -I/usr/local/include -L/usr/local/lib
conftest.c >&5
conftest.c:27:21: glib.h: No such file or directory
which is Not Good.
Also, GTK+ and GLIB were installed in /usr/local/lib
It appears that the GLib test macro isn't doing enough checking, as is
it found GLib present, which it is, but not enough of it is present to
*compile* software that uses it.
I suspect you have GLib, but *not* the GLib development package,
installed; packages for libraries in Linux tend to have "user" packages,
which just install shared libraries but not headers or archive
libraries, and "developer" packages, which install headers and perhaps
archive libraries.
If you installed GLib from an RPM, there's probably an RPM with a name
like "glib-devel" or something such as that; you'll need to install
that. (The same applies to GTK+.)
The output of uname -a:
Linux guinan.rti.org 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005
i686
i686 i386 GNU/Linux
I think that FC3 supports it as a 32-bit.
It would probably say "x86-64" or "x86_64" or "amd64" or something such
as that if you had a 64-bit processor and FC3 supported it as such.
*Is* it an AMD64/Intel 64/x86-64/whatever processor, or just a 32-bit
processor?
Is there some configuration that needs to be set to have wireshark for
32-bit?
Not unless you're building on a 64-bit platform that defaults to
building 64-bit - and, in that case, there's no option we offer to do
non-default builds.
I only asked because I was thinking that there *might* have been a bug
in the configure script's checks to determine the format to print 64-bit
numbers. The only bug is that the configure script isn't checking
whether you have a developer package installed; if it "finds" GLib but
the headers aren't present, all subsequent configuration file tests that
use GLib features, such as the test for 64-bit print formats, could fail.
