Wireshark mailing list archives

Re: OSX 32-bit build on 10.5.x (Leopard) no longer supported?


From: Guy Harris <guy () alum mit edu>
Date: Mon, 24 Jun 2013 18:14:26 -0700


On Jun 24, 2013, at 2:48 PM, David Ameiss <netshark () ameissnet com> 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:

        https://developer.apple.com/library/mac/#releasenotes/DeveloperTools/RN-dyld/

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 -lgmodu
 le-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.

Michael?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: