Comment author: @xavierleroy

Thanks for diagnosing the problem and for the proposed patch. I'm in the process of applying the patch to the 3.10 bugfix branch, but I'm running into a problem. On our MacOS 10.4/PPC machine, __DARWIN_UNIX03 is not defined when compiling in 32-bit mode, but is defined in 64-bit mode (gcc -m64). Cf. /usr/include/sys/cdefs.h:

#if defined(_APPLE_C_SOURCE) || defined(_XOPEN_SOURCE) || defined(_POSIX_C_SOUR
CE) || defined(LP64)
...
#define __DARWIN_UNIX03 1
#elif
...

(Notice the "defined(LP64)".)

Is there a preprocessor symbol other than __DARWIN_UNIX03 that would identify more precisely the change from 10.4 to 10.5? Otherwise, I'm afraid more "configure" magic is needed.

Comment author: gordonhenriksen

See if the attached patch works better on Tiger.

Comment author: @dbuenzli

Applied the second patch after ./configure on a 10.5, PPC G4. Built with fastworld.sh and everything seems to work so far.

Best,

Daniel

Comment author: @alainfrisch

I've applied the second patch on the HEAD branch. This is mainly to test the natdynlink branch on various machines, and might go away (Xavier will decide).

Comment author: @xavierleroy

Sorry for not documenting my changes in this PR. Inspired by a Web search, I commited a fix in the 3.10 release branch that uses

#ifdef _STRUCT_PPC_EXCEPTION_STATE

and

#ifdef _STRUCT_X86_EXCEPTION_STATE

to discriminate between 10.4 and 10.5. It seems to work fine under 10.4, and we'll have 10.5 installs to test it in a couple of days. Stay tuned.

Comment author: @alainfrisch

Oops, sorry, I did not check the release310 branch. Xavier's works on 10.5 if one replaces _STRUCT_X86_EXCEPTION_STATE with _STRUCT_X86_EXCEPTION_STATE32.

Comment author: gordonhenriksen

On Leopard, release310 shows...

ppc32: okay
ppc64: compiles, fails at runtime as before
x86: does not compile:

gcc -I../byterun -DCAML_NAME_SPACE -DNATIVE_CODE -DTARGET_i386 -DSYS_macosx -O -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o signals_asm.o signals_asm.c
signals_asm.c: In function ‘segv_handler’:
signals_asm.c:193: error: ‘struct __darwin_mcontext32’ has no member named ‘ss’
signals_asm.c:193: error: ‘struct __darwin_mcontext32’ has no member named ‘ss’

What's wrong with comparison of MAC_OS_X_VERSION_MIN_REQUIRED to check the OS version?

Comment author: @alainfrisch

Gordon: did you try with the modification I suggest (_STRUCT_X86_EXCEPTION_STATE -> _STRUCT_X86_EXCEPTION_STATE32)?

Comment author: @xavierleroy

Xavier's works on 10.5 if one replaces _STRUCT_X86_EXCEPTION_STATE with _STRUCT_X86_EXCEPTION_STATE32.

Sorry for the typo. Fixed in 3.10 branch.

What's wrong with comparison of MAC_OS_X_VERSION_MIN_REQUIRED to check the OS version?

Probably nothing. It's just that I found the documentation comments for these macros in <AvailabilityMacros.h> somewhat unclear on whether they can reliably be used to determine the version of the development environment (as opposed to controlling the versions of the execution environment for the program being compiled).

Comment author: gordonhenriksen

In this case, I'm pretty sure that detecting the development
environment is actually the wrong thing to do. If the SDK is
detected rather than the target, then a package maintainer using
MACOSX_DEPLOYMENT_TARGET to build a backwards-compatible binary
would encounter compilation errors on Leopard.

setenv MACOSX_DEPLOYMENT_TARGET 10.4 actually engages a lot of
backwards compatibility machinery--both in the headers and at
runtime(!)--in order to revert both the runtime and compile-time
changes. That's why using it fixes the compilation errors and avoids
the ppc64 crash. (Of course, it also puts ocaml in a backwards
compatibility penalty box where it cannot benefit from the latest
APIs and standards compliance work.)

Comment author: @xavierleroy

My patch didn't quite work with "setenv MACOSX_DEPLOYMENT_TARGET 10.4",
and Gordon's patch didn't quite work under 10.4, but after tweaking we now have (in the 3.10 bugfix branch) code that works under 10.4, 10.5, and 10.5 with
"MACOSX_DEPLOYMENT_TARGET 10.4". Phew!