Wireshark-dev: Re: [Wireshark-dev] OSX 32-bit build on 10.5.x (Leopard) no longer supported?
From: Guy Harris <[email protected]>
Date: Mon, 24 Jun 2013 18:14:26 -0700
On Jun 24, 2013, at 2:48 PM, David Ameiss <[email protected]> wrote:

> On my Leopard 10.5.8 system (yes, it's ancient - but needed to build 32-bit plugins) the last version of Wireshark that works is 1.8.6. When I try 1.8.7, 1.8.8, or 1.10.0, I get the error
> dyld: unknown required load command 0x80000022

That's LC_DYLD_INFO_ONLY, which is LD_DYLD_INFO plus the LC_REQ_DYLD flag.  LC_DYLD_INFO was introduced to OS X in 10.6:


and a quick check of the binaries indicates that it's in all the executables in the Leopard install.

The configure script reports, in the build logs, that the 10.5 buildbot is powerpc-apple-darwin9.8.0, so it thinks it's running 10.5.8 (Darwin n.m.x corresponds to OS X 10.{n-4}.m), but somehow the linker is producing binaries using 10.6-and-later Mach-O load commands.

The page above says

	When building a product targeted at OS X v10.6, the linker, ld, creates Macho-O images that contain only the new LINKEDIT format; these programs do not run on OS X v10.5 and earlier. When targeting OS X v10.5, the linker creates images that contain both the new and traditional LINKEDIT segment format; this practice allows programs to run on OS X v10.5 and run very efficiently on OS X v10.6. (When targeting OS X v10.4 or earlier, the linker produces only the traditional format.)

Dumpcap is being linked with the command

	/bin/sh ./libtool --tag=CC   --mode=link ccache gcc  -no-cpp-precomp -g -O2 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wpointer-arith -Wno-pointer-sign -Wcast-align -Wformat-security -Wold-style-definition -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/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/X11/include/freetype2 -I/usr/X11/include -I/usr/X11/include/libpng12    -Wl,-search_paths_first  -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -o dumpcap dumpcap-capture-pcap-util-unix.o dumpcap-capture_opts.o dumpcap-capture-pcap-util.o dumpcap-capture_stop_conditions.o dumpcap-clopts_common.o dumpcap-conditions.o dumpcap-dumpcap.o dumpcap-pcapio.o dumpcap-ringbuffer.o dumpcap-sync_pipe_write.o dumpcap-tempfile.o dumpcap-version_info.o wsutil/libwsutil.la -L/usr/local/lib -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lpcap -framework CoreServices  -lz

There's no -macosx_version_min flag there, so I'd *expect* it to target 10.5 by default, given that it's *running* on 10.5.  Maybe "[creating] images that contain both the new and traditional LINKEDIT segment format", at least with that version of the linker, is not being done correctly; I'd assume that it puts in a load command for the "traditional LINKEDIT segment format" and a LD_DYLD_INFO, *without* LC_REQ_DYLD, so that the 10.5 dynamic linker silently ignores LD_DYLD_INFO and the 10.6 and later dynamic linkers use it.

However, the LC_REQ_DYLD flag is set (that's the 0x80000000 part), which means the dynamic linker rejects the command rather than silently ignoring it.  That would be appropriate if building on 10.5 and targeting 10.6; I wouldn't *expect* that to be the default, but maybe software on the 10.5 buildbot was updated in a way that made targeting 10.6 the default.