Compilation with mac os X 10.5 (leopard)

[castano]

Compilation with mac os X 10.5 (leopard)

[GoogleCodeExporter]

Thanks for diagnosing the problem and providing the patches. Your solution for 
1 and
2 looks fine. I'm not sure that 3 is the right thing to do. There must be a way 
of
retrieving the caller address on Leopard. I'll see if I can get a leopard 
system and
figure that out.

Original comment by [email protected] on 19 May 2008 at 8:15

• Changed state: Accepted

[GoogleCodeExporter]

Hmm... I tried to compile on Leopard with your suggestions, and got the 
following error:

 execinfo.h: No such file or directory

I made sure that the file exists, and that its path (/usr/include) is in the 
include
directories. I also tried setting MACOSX_DEPLOYMENT_TARGET=10.5, but that 
didn't make
any difference.

Any ideas? This file was introduced in 10.5, is there anything special that 
needs to
be done for the compiler to find it?

Original comment by [email protected] on 23 May 2008 at 7:59

[GoogleCodeExporter]

I also tried the -mmacosx-version-min=10.5 cflag, but the problem persists.

Original comment by [email protected] on 23 May 2008 at 8:02

• Changed title: Compilation with mac os X 10.5 (leopard)

[GoogleCodeExporter]

I think the problem is that the CheckIncludeFiles macro does not search in the 
appropriate SDK path, but only in /usr/include, that links to SDK10.5

So, HAVE_EXECINFO_H is not set correctly when compiling for the 10.4 SDK. I've
disabled that explicitely on DARWIN (#undef HAVE_EXEC_INFO_H) and that seems to 
work
fine. The other option is to add the following CFLAGS:

-mmacosx-version-min=10.5
-isysroot /Developer/SDKs/MacOSX10.5.sdk

I was not able to reproduce the third issue that you describe, but maybe that 
only
happens on Intel.

Original comment by [email protected] on 23 May 2008 at 10:22

[GoogleCodeExporter]

I've checked in some changes, let me know how that works for you. Thanks!

Original comment by [email protected] on 23 May 2008 at 10:23

[GoogleCodeExporter]

I just checkout the last version : 
. The issue 1 & 2 are fixed
. The third issue (ucontext) isn't specific to intel platform, but apparently 
because it assumes the last version of Darwin 
doesn't support ucontext.  

Suggestion of fix : 

    static void * callerAddress(void * secret)
    {
#   if NV_OS_DARWIN && NV_CPU_PPC && defined(_STRUCT_MCONTEXT)
#       if defined(_STRUCT_MCONTEXT)
            ucontext_t * ucp = (ucontext_t *)secret;
            return (void *) ucp->uc_mcontext->__ss.__srr0;
#       elif !defined(_STRUCT_MCONTEXT)
            ucontext_t * ucp = (ucontext_t *)secret;
            return (void *) ucp->uc_mcontext->ss.srr0;
#       endif
#   elif NV_OS_DARWIN && NV_CPU_X86 && defined(_STRUCT_MCONTEXT)
#       if defined(_STRUCT_MCONTEXT)
            ucontext_t * ucp = (ucontext_t *)secret;
            return (void *) ucp->uc_mcontext->__ss.__eip;

#       elif !defined(_STRUCT_MCONTEXT)
            ucontext_t * ucp = (ucontext_t *)secret;
            return (void *) ucp->uc_mcontext->ss.eip;
#       endif

Tested under MacOS 10.5.2 (with a G4 PPC and Intel Core Duo)

Sorry to be late to answer you. Did you solve your problem of path ? 

Original comment by [email protected] on 24 May 2008 at 3:35

[GoogleCodeExporter]

I've finally tested and checked in the fix that you proposed. Thanks!

Original comment by [email protected] on 27 Jun 2008 at 6:53

• Changed state: Fixed