Bug? Cuda 2.3 on Snow Leopard (10A421a) with gcc 4.2.1

I’m trying to run CUDA 2.3 with the CUDA 2.3.1 drivers on Mac OS X 10.6 (10A421a) with gcc i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646).

If I try to build the examples I get:
$ make
make -C src/3DFD/
/usr/include/stdlib.h(272): error: expected an expression

/usr/include/stdlib.h(272): error: expression must have (pointer-to-) function type

/usr/include/stdlib.h(272): error: type name is not allowed

/usr/include/stdlib.h(274): error: expected a “)”

looking at /usr/include/stdlib.h(272):
#ifdef BLOCKS
int atexit_b(void (^)(void)); <---- line 272
void *bsearch_b(const void *, const void *, size_t,
size_t, int (^)(const void *, const void ));
#endif /

So it looks like Apple’s new closures are enabled. Do I have something wrong with my configuration (I didn’t knowingly change any thing form the standard release) or is this a bug/misconfiguration somewhere in the Nvidia toolchain?

I’m running under the same software configuration as you and I got the same error during the compilation of my project. When I tried to compile it under Ubuntu 9.04 with CUDA 2.3, I have no problem. I think we can blame nvdia or apple :no: .

Ok, if I understand, when Snow Leopard comes out, we are lost!!?!

Seriously, did someone successfully installed CUDA 2.3 with XCode 3.2?

I have exact same problem here. I haven’t been able to get any recent version of cuda to compile in SL.

Same here,

I tried to add
CFLAGS += -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk
to the main makefile hoping it would force the compiler to use the 10.5 header files; but that did not work.

It would be nice to see someone from nvidia comment here.


It would be nice to see someone from nvidia comment here.


Try using the older gcc-4.0. I changed the gcc symlink from gcc-4.2 to gcc-4.0 . nvcc works for me now on snow leopard.

I tried this, but got these errors:

[codebox]hani:C root# pwd

/Developer/GPU Computing/C

hani:C root# make

a - obj/release/bank_checker.cpp.o

a - obj/release/cmd_arg_reader.cpp.o

a - obj/release/cutil.cpp.o

a - obj/release/stopwatch.cpp.o

a - obj/release/stopwatch_linux.cpp.o

a - obj/release/multithreading.cpp.o

make -C src/3DFD/

ld: warning: in obj/release/3dfd.cu.o, file is not of required architecture

ld: warning: in /usr/local/cuda/lib/libcudart.dylib, file is not of required architecture

Undefined symbols:

“_main”, referenced from:

  start in crt1.10.6.o

ld: symbol(s) not found

collect2: ld returned 1 exit status

make[1]: *** […/…/bin/darwin/release/3dfd] Error 1

make: *** [src/3DFD/Makefile.ph_build] Error 2

hani:C root# find . -type f -name 3dfd.cu.o


hani:C root# file ./src/3DFD/obj/release/3dfd.cu.o

./src/3DFD/obj/release/3dfd.cu.o: Mach-O object i386


Am I doing something stupid? It clearly shows that the file is targeting i386 … is there some way to tell NVCC to target x86_64? Do I not have it configured correctly?

The CUDA libraries are only 32-bit. you cannot build a 64-bit cuda application yet. Add -m32 to the compiler and linker options and these problems will go away.

Didn’t work for me.

I tried building a minimal test app (consisting of a single .cu file) and it looks like it is the linker phase of nvcc that is causing trouble.

Compiling to ptx works fine.

Using driver API calls in Snow seems to be working also. I havent tried launching a PTX kernel though - just tested memory operations.

Interesting. The combo of pointing the gcc link to gcc-4.0 and compiling with -m32 fixed all my snow leopard woes except for one: the cuda driver kernel extension doesn’t seem to load after a reboot of my system. I need to reinstall the driver after each reboot. Sorry that you are having trouble. Did you make sure that you added -m32 to both the compile and like phases of the build including the nvcc compiles?

I guess I added -m32 where needed, but I’d appreciate if you can post your modified make file so I can take a look.

Your problem with needing to reinstall the driver after every reboot has been discussed (and solved) on another post here.
It is just a permission problem by the installer that prevents the CUDA kext from being loaded correctly.

This should fix it (works for me)
sudo chmod g-w /System/Library/StartupItems/CUDA/*
sudo chmod g-w /System/Library/StartupItems/CUDA/


Thanks for the permissions fix!

In building the code in /Developer/CUDA, I changed the file /Developer/CUDA/common/common.mk so that lines 99,100, and 101 are:




all the cuda example code built fine after that.

In my own personal project (a very small program), I changed from:

llvm-gcc -O3 -Wall -I/usr/local/include/ -I/usr/local/cuda/include/ -c mep8.cpp

nvcc -O3 -arch sm_11 -c fitness8.cu

llvm-gcc -O3 -o mep8 mep8.o fitness8.o -L/usr/local/cuda/lib -lstdc++ -lmqaapi -lpthread -lcuda -lcudart


llvm-gcc -m32 -O3 -Wall -I/usr/local/include/ -I/usr/local/cuda/include/ -c mep8.cpp

nvcc -m32 -O3 -arch sm_11 -c fitness8.cu

llvm-gcc -m32 -O3 -o mep8 mep8.o fitness8.o -L/usr/local/cuda/lib -lstdc++ -lmqaapi -lpthread -lcuda -lcudart

That was it to get all of the cuda examples and my own code to work under 10.6, after I had installed the latest xcode tools and changed the gcc symbolic link in /Developer/usr/bin to point to gcc-4.0 instead of gcc-4.2. After that the code ran as expected and gave the same results that I was getting when running with 10.5.

forgot one little detail: change the symbolic link for g++ in /Developer/usr/bin from g+±4.2 to g+±4.0

Damn - that’s probably what I missed.

I changed the symlink from /usr/bin but didn’t think about /Developer/usr/bin


Well, actually the change to /Developer/usr/bin is not necessary.

What I had missed, was that I had changed the symlink to gcc, but not to g++

All compiled now - great!

Okay so this fix works for the terminal, but when I build on xcode (which supposedly does nothing but run my “external” makefile, the damn thing still screws up (stdio.h errors). Has anyone figured out why xcode won’t let nvcc use the old compiler? I’ve checked every env variable set by xcode and they none of them mention gcc/g++ 4.2

edit: I figured this out. turns out that xcode uses the /Developer/usr/bin directory, so I needed to alter the symbolic links in there as well.