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.