Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Having the buildbot build Wireshark 64-bit for Mac OS X (was

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Wed, 28 Apr 2010 15:10:30 -0400
Guy Harris wrote:
On Apr 27, 2010, at 5:41 PM, Jeff Morriss wrote:

On Tue, Apr 27, 2010 at 4:05 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
On Apr 27, 2010, at 12:37 PM, Jeff Morriss wrote:
But: would the header files have to be different?  Linux and Solaris
seem get away with one set of header files for both the 32- and 64-bit
libraries.
I'm not sure how they handle 32-bit vs. 64-bit GLib, given that the 64-bit /usr/local/lib/glib-2.0/include/glibconfig.h installed on my machine has #defines and typedefs such as
My FC 10 system has multiple copies of that file in different directories:

/usr/lib/glib/include/glibconfig.h
/usr/lib/glib-2.0/include/glibconfig.h
/usr/lib64/glib/include/glibconfig.h
/usr/lib64/glib-2.0/include/glibconfig.h

OK, so I guess that's why glibconfig.h is under /usr/lib* - to let systems with /usr/lib and /usr/lib64 (or whatever they do to support 32-bit and 64-bit userland) have separate configurations.

However, /usr/local/include/glib-2.0/glib/gtypes.h just includes <glibconfig.h>, so it relies on "pkg-config --cflags" being used, and that prints

	-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include

I get:

	-I/usr/include/glib-1.2 -I/usr/lib64/glib/include

on my machine.  Does that mean that pkg-config somehow needs to know whether you're building 32-bit or 64-bit?  Are there, for example, two separate GLib (and presumably GTK+) packages, one 32-bit and one 64-bit?  What does

	pkg-config --list-all | egrep -i glib

print?

That gives:

glib-2.0                    GLib - C Utility Library
gthread                     GThread - Thread support for GLib
gmodule-2.0                 GModule - Dynamic module loader for GLib
gmodule-export-2.0          GModule - Dynamic module loader for GLib
gobject-2.0                 GObject - GLib Type, Object, Parameter and Signal Library
dbus-glib-1                 dbus-glib - GLib integration for the free desktop message bus
gio-2.0                     GIO - glib I/O library
glib                        GLib - C Utility Library
gio-unix-2.0                GIO unix specific APIs - unix specific headers for glib I/O library
gmodule                     GModule - Dynamic module loader for GLib
gthread-2.0                 GThread - Thread support for GLib
libsoup-2.4                 libsoup - a glib-based HTTP library
gmodule-no-export-2.0       GModule - Dynamic module loader for GLib

but I do have two pkgconfig files for glib:

/usr/lib/pkgconfig/glib-2.0.pc
/usr/lib64/pkgconfig/glib-2.0.pc

but you couldn't handle the GLIB_SIZEOF_ definitions without #ifdefs.  They might either manually, or with a tool that makes "fat" versions of header files given two different versions of the header file for different platforms, do it with #ifdefs, or they might have different include directories for 32-bit and 64-bit.  OS X doesn't support different include directories for 32-bit and 64-bit, so that option isn't open to OS X.
> > ... but apparently that won't work with OS X.

Nope - not unless there's some way to tell pkg-config whether you want to build with the 32-bit or 64-bit version of GLib and GTK+ (and any other packages we use).

To get it to build 32-bit I have to do this:

CFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig ./configure

(Actually, it took a bit more work than that as apparently I didn't have the 32-bit version of *all* the libraries and development packages I needed, but a half dozen "yum install"s fixed that.)