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. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
