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] [Wireshark-bugs] [Bug 2979] can not open wireshark on mac PP

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 28 Oct 2008 11:28:55 -0700

On Oct 28, 2008, at 9:08 AM, Stephen Fisher wrote:

It would be nice to have a PPC version available. Maybe we could build
GLib/GTK and friends on the Intel buildbot for the PPC architecture.

That might be possible - but it's a bit tricky.

For one thing, if you build and install GLib, the glibconfig.h header has some configuration-time characteristics of the machine embedded in it, so, while you could build a fat^WUniversal version of GLib, so that you can link either a PPC or x86 binary against the same library, you'd have to manually tweak glibconfig.h to make a "fat" version of it that, for example, uses #ifdef/#if to decide how G_BYTE_ORDER, and all the "xxx_TO_LE" and "xxx_TO_BE" macros should be defined (and, if we want 3-way or 4-way universal, how G_GINT64_xxx and G_GUINT64_xxx and G_GSIZE_xxx and G_GSSIZE_xxx and so on are defined).

glibconfig.h is installed under /usr/lib or /usr/local/lib or..., rather than /usr/include or /usr/local/include or...; my guess is that's so that "include" can be shared across architectures ("lib" can't, unless you have some fat-binary notion such as NeXTStEP and OS X have). *If* it's possible to configure glib to have different versions of "lib" (configuring with --libdir= might do that), that might work...

...as long as the resulting builds for PPC and x86 (and PPC64 and x86_64, if we go four-way for Leopard) can arrange to look for the libraries inside the application bundle itself, rather than having the PPC and x86 versions look for them in different places.

The second problem is that the configuration-time characteristics in question are done by running a program to, for example, probe the byte order of the machine. Thus, *those* programs would have to be compiled for PPC and run through Rosetta.

If you run the configuration script with the CFLAGS environment variable set to include "-arch ppc", that might handle this; I tried that with libpcap and tcpdump and, from looking at the config.log file, it appears that the test programs were built with "-arch ppc". It *also* meant that the Makefile set CFLAGS to include "-arch ppc", so it built for PPC.

(Note that the resulting tcpdump crashed and burned, because Rosetta doesn't know anything about BPF.)

The configure scripts reported a host system type of "i686-apple- darwin9.5.0", so any place where the configure script checks "$host_arch" or whatever it's called won't work, unless that's also forced. (Note: "host", in current GNU autotools, refers to the machine for which you're building the application; "target" refers to the target for which the generated application will generate code if it's a compiler or assembler or linker or.... I think this is for a "Canadian Cross":

	http://www.airs.com/ian/configure/configure_6.html

where you might, for example, build, on a Linux/x86 machine, a compiler that runs on Solaris/SPARC and generates code for an embedded MIPS target.)

So this might be doable.