[ZooLib-dev] Zoolib on XCode (Mac OS 10.3) -- 99.71% there

[Richard C. <rd_...@sb...>]

I've been trying to get Zoolib to compile and run under the new XCode 
development environment, and a few simple changes get all the files but 
one to compile.

Settings:
1. Get the build settings (select the target, touch "get info", select 
the build panel) and set the header search path to 
"/Developer/Headers/FlatCarbon"
2. In the same panel, set OTHER_CFLAGS to -fasm-blocks
3. If you want to cut down on the warnings, append 
-Wno-non-virtual-dtor to the warning flags (also in the build settings)

File changes:
1. In src/config/zconfigl.h, find the lines
#   elif defined(__GNUC__)
#       if __BEOS__
#           define ZCONFIG_OS ZCONFIG_OS_Be

and insert 4 lines immediately after:
#       elif TARGET_API_MAC_CARBON
#           define ZCONFIG_OS ZCONFIG_OS_Carbon
#       elif __MACOS__
#           define ZCONFIG_OS ZCONFIG_OS_MacOS7

2. In src/platform/mac/ZOSWindow_Carbon.cpp, scroll down to void 
ZOSApp_Carbon::Internal_SetCursor(const ZCursor& inCursor) and change 
Handle(...) to (Handle)(...) in two lines:

             ZUtil_Mac_LL::HandleLocker 
locker2(Handle(theCursorHandle[0]->crsrMap));
becomes
             ZUtil_Mac_LL::HandleLocker 
locker2((Handle)(theCursorHandle[0]->crsrMap));

             ZUtil_Mac_LL::HandleLocker 
locker3(Handle(theCursorHandle[0]->crsrData));
becomes
             ZUtil_Mac_LL::HandleLocker 
locker3((Handle)(theCursorHandle[0]->crsrData));


3. In src/platform/mac/ZTextCoder_Mac.cpp, add "#include <stdexcept>" 
near the top.

4. Now we get to the one broken file: src/platform/mac/ZThreadTM.cpp:
4a. There is no pool_alloc.h file under xcode. That needs to be 
#ifdef'ed out.
4b. The ZAsertCompile line causes an error, as option "far_data" isn't 
defined. (Maybe add a check for __GNUC__ ?)
4c. The compiler chokes on the inline assembly code for "static asm 
bool sTestAndSet(register int32& ioInt32) "

First, using "static asm bool" causes the compiler to emit several 
dozen false errors after this block. using "static bool 
sTestAndSet(register int32& ioInt32) { asm { ... } }" fixes that, 
though I haven't tested this back in CW8 nor have I done a comparative 
disassembly to see if the new form is setting up a new calling context.

Second, the compiler refuses to recognize ioInt32 as an operand ("block 
operand not recognized"). Changing from a reference to a pointer gets 
the assembler to work, but changes the semantics.

(Note: Apple's documentation says if there's a bit of inline assembly 
that works in Code Warrior, but not in XCode, Apple should get a bug 
report. I haven't filed one...yet. I wanted to see what resolution we 
could get here first, and use whatever we find as part of the report.)

If you make those changes, it compiles but fails with an illegal access 
error (a null pointer dereference) in the first assembly instruction.

I suspect this could all work if the assembly code were placed into an 
asm { } block directly in sEnterCritical, but I wanted to put it out to 
the list and see what the best solution was.

  ...Richard