If I try to run the resulting ppc binary, I get the following (I've not tried the Intel version yet, but I assume I'll get the same error):
gcc version 4.0.1 (Apple Computer, Inc. build 5247)
It's a Makefile based project, so I followed the instructions and added the following to the compiler & linking options:
-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
Before adding these, it worked just great with GCC 4.0.1. What's really weird is that I reverted to my Makefile from yesterday and I *still* have the problems, even with clean builds. Except now the error reads:
/usr/bin/ld: warning can't open dynamic library: /var/tmp//ccTZ2Xk3.out referenced from: build/debug/lib/Foobar.framework/Foobar (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
Note the path is different (/var vs. /Developer/...) I tried purging cruft from /var/tmp and /tmp but to no avail! Is there a secret cache somewhere? I don't seem to be able to undo this!!!
The nitty gritty details are below.
Help!
Dave.
---
If I run otool -L against the dylib inside the framework, I get:
otool -L build/debug/lib/Foobar.framework/Foobar
build/debug/lib/Foobar.framework/Foobar:
@executable_path/../Frameworks/Foobar.framework/Libraries/libfoobar.dylib (compatibility version 0.0.0, current version 0.0.0)
/var/tmp//ccTZ2Xk3.out (compatibility version 0.0.0, current version 0.0.0)
/var/tmp//ccfi3B8K.out (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.22.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2)
The unit test is built like this:
g++ -fPIC -arch ppc -g -DDEBUG -D_DEBUG -fnext-runtime -fobjc-exceptions -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Fbuild/debug/lib -c -o build/debug/obj/Foobar/BasicTest.o ./UnitTests/BasicTest.m
g++ -o build/debug/bin/BasicTest build/debug/obj/Foobar/BasicTest.o \
-fPIC -arch ppc -g -DDEBUG -D_DEBUG -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -lobjc -framework Foundation \
-Fbuild/debug/lib -framework Foobar \
-framework ExceptionHandling \
-lLIBX -lLIBY -Lbuild/debug/lib/Foobar.framework/Versions/Current/Libraries
I've spent most of the afternoon trying to Google this, but it doesn't look like anyone has run into it before. I'm building the framework as follows:
g++ -fPIC -arch ppc -g -DDEBUG -D_DEBUG -fnext-runtime -fobjc-exceptions -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Fbuild/debug/lib -c -o build/debug/obj/Foobar/Foobar.o Foobar.mm
And linking it like this:
g++ -o build/debug/lib/Foobar.framework/Versions/1.0/Libraries/libfoobar.dylib build/debug/obj/Foobar/Foobar.o \
-dynamiclib -flat_namespace -install_name \
@executable_path/../Frameworks/Foobar.framework/Libraries/libfoobar.dylib \
-fPIC -arch ppc -g -DDEBUG -D_DEBUG -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk \
-Lbuild/debug/lib/Foobar.framework/Libraries -lLIBX -lLIBY -lobjc -framework Foundation
There's also some shell script bits that build up the .framework directory structure, including linking from ./Versions/1.0/Libraries/libfoobar.dylib to ./Foobar and also some annoying install_name_tool stuff to fix up the locations of LIBX and LIBY in the framework relative to @executable_path.