Compilation with mac os X 10.5 (leopard)

[GoogleCodeExporter]

I had some trouble to compile the nvidia-texture-tools with Mac OS X 10.4 
(leopard) : 

1. type not found
nvidia-texture-tools 2/src/nvcore/DefsGnucDarwin.h:54: error: ‘uint8_t’ 
does not name a type
nvidia-texture-tools 2/src/nvcore/DefsGnucDarwin.h:57: error: ‘uint16_t’ 
does not name a type
nvidia-texture-tools 2/src/nvcore/DefsGnucDarwin.h:60: error: ‘uint32_t’ 
does not name a type
nvidia-texture-tools 2/src/nvcore/DefsGnucDarwin.h:63: error: ‘uint64_t’ 
does not name a type
nvidia-texture-tools 2/src/nvcore/DefsGnucDarwin.h:67: error: ‘uint32’ does 
not name a type

fixed : added #include <stdint.h>inside the DefsGnucDarwin.h file

2. Backtrace  & abi
nvidia-texture-tools 2/src/nvcore/Debug.cpp: In function 
‘void<unnamed>::nvPrintStackTrace(void**, int, int)’:
nvidia-texture-tools 2/src/nvcore/Debug.cpp:132: error: ‘backtrace_symbols’ 
was not declared 
in this scope

fixed : miss  execinfo and cxxabi headers
#if NV_OS_DARWIN
#   include <unistd.h>  // getpid
#   include <sys/types.h>
#   include <sys/sysctl.h>  // sysctl
#   include <ucontext.h>
#   include <execinfo.h>
#   include <cxxabi.h>
#endif

3. context
nvidia-texture-tools 2/src/nvcore/Debug.cpp: In function 
‘void*<unnamed>::callerAddress(void*)’:
nvidia-texture-tools 2/src/nvcore/Debug.cpp:176: error: ‘struct 
__darwin_mcontext32’ has no 
member named ‘ss’

These errors are related to Unix'03 compliance; as of Leopard, many nonstandard 
symbols have 
been moved out of the user namespace.

fixed : workaround using the flag __DARWIN_UNIX03 
    static void * callerAddress(void * secret)
    {
#   if NV_OS_DARWIN && NV_CPU_PPC && !__DARWIN_UNIX03
        ucontext_t * ucp = (ucontext_t *)secret;
        return (void *) ucp->uc_mcontext->ss.srr0;
#   elif NV_OS_DARWIN && NV_CPU_X86 && !__DARWIN_UNIX03
        ucontext_t * ucp = (ucontext_t *)secret;
        return (void *) ucp->uc_mcontext->ss.eip;
#   elif NV_CPU_X86_64
        // #define REG_RIP REG_INDEX(rip) // seems to be 16
        ucontext_t * ucp = (ucontext_t *)secret;
        return (void *)ucp->uc_mcontext.gregs[REG_RIP];
#   elif NV_CPU_X86 && !__DARWIN_UNIX03
        ucontext_t * ucp = (ucontext_t *)secret;
        return (void *)ucp->uc_mcontext.gregs[14/*REG_EIP*/];
#   elif NV_CPU_PPC && !__DARWIN_UNIX03
        ucontext_t * ucp = (ucontext_t *)secret;
        return (void *) ucp->uc_mcontext.regs->nip;
#   else
        return NULL;
#   endif

Original issue reported on code.google.com by amne...@mac.com on 19 May 2008 at 6:17

[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 cast...@gmail.com 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 cast...@gmail.com 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 cast...@gmail.com 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 cast...@gmail.com 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 cast...@gmail.com 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 amne...@mac.com on 24 May 2008 at 3:35

[GoogleCodeExporter]

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

Original comment by cast...@gmail.com on 27 Jun 2008 at 6:53

• Changed state: Fixed