Help: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/var/tmp//ccTZ2Xk3.out

/usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/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)

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):

dyld: Library not loaded: /var/tmp//ccTZ2Xk3.out

Referenced from: /Users/davem/Work/Foobar/build/debug/lib/Foobar.framework/Libraries/libfoobar.dylib

Reason: image not found

Trace/BPT trap

I'm using this GCC:

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.