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: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 27 Apr 2010 13:05:33 -0700
On Apr 27, 2010, at 12:37 PM, Jeff Morriss wrote:

> Guy Harris wrote:
>> On Apr 27, 2010, at 11:36 AM, Jeff Morriss wrote:
>> 
>>> Given that the MacOS buildbot (at least the Intel one) is so fast, would 
>>> it make sense to also build a 64-bit version of Wireshark?
>> 
>> As long as we make sure it works on Leopard before we offer it to Leopard users.
> 
> Well, yes :-).
> 
> I guess I had assumed that most of the developers were using 64-bit, it 
> was just a question of what is being built by the buildbot.

I don't know how many of the developers using OS X are using Tiger, Leopard, Snow Leopard, or earlier releases, but, unless they've made an effort to build 64-bit, only the developers using Snow Leopard are using 64-bit (unless they have 32-bit-only machines, i.e. Intel Core Duo or Core Solo, rather than Core 2 or Core i[0-9] or the later Xeons).

> Ah, so MacOS doesn't have, say, "/usr/lib/" and "/usr/lib64/" for 32- 
> and 64-bit libraries?

Nope:

	$ file /usr/lib/libpcap.dylib
	/usr/lib/libpcap.dylib: Mach-O universal binary with 3 architectures
	/usr/lib/libpcap.dylib (for architecture x86_64):       Mach-O 64-bit dynamically linked shared library x86_64
	/usr/lib/libpcap.dylib (for architecture i386): Mach-O dynamically linked shared library i386
	/usr/lib/libpcap.dylib (for architecture ppc7400):      Mach-O dynamically linked shared library ppc

That's *the* libpcap for both 32-bit and 64-bit binaries (as well as for PowerPC binaries run under the Rosetta binary-to-binary translator, although, in the particular case of libpcap, that wouldn't work - Rosetta doesn't support BPF ioctls).

Mac OS X uses the "fat binary" mechanism from NeXTStEP:

	http://en.wikipedia.org/wiki/Fat_binary

(at least according to the article, originally called "multi-architecture binaries", now called "universal binaries", but with the tool to manipulate them called "lipo", I suspect the notion of fatness is in there and was probably in there from Day One...) to handle 32-bit vs. 64-bit as well as PowerPC vs. x86 (as the article notes, it was originally put there for 68k vs. x86, to support both NeXT's hardware and NeXTStEP-on-PCs).

> Or is this because we're shipping glib, not using one from the OS?

If OS X shipped with GLib, Apple would have to build it fat too.

> 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

	typedef signed long gint64;
	typedef unsigned long guint64;

	#define G_GINT64_CONSTANT(val)  (val##L)
	#define G_GUINT64_CONSTANT(val) (val##UL)
	#define G_GINT64_MODIFIER "l"
	#define G_GINT64_FORMAT "li"
	#define G_GUINT64_FORMAT "lu"

	#define GLIB_SIZEOF_VOID_P 8
	#define GLIB_SIZEOF_LONG   8
	#define GLIB_SIZEOF_SIZE_T 8

in it.  Those would work in 64-bit mode, but not in 32-bit mode.  The 32-bit versions of *some* of them would probably work in 64-bit mode:

	typedef signed long long gint64;
	typedef unsigned long long guint64;

	#define G_GINT64_CONSTANT(val)  (val##LL)
	#define G_GUINT64_CONSTANT(val) (val##ULL)
	#define G_GINT64_MODIFIER "ll"
	#define G_GINT64_FORMAT "lli"
	#define G_GUINT64_FORMAT "llu"

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.