>> What is ccpython.cc and why do I need it? I don't see it used during >> the build process. Martin> It might be MAINOBJ, and it is located Modules. Whether it is on Martin> your system, I don't know - see configure.in. I think you misunderstood what I wrote. As far as I can tell, ccpython.cc is not compiled when building python.exe on my Mac. Accordingly, the link step should use gcc, not c++. >> Regardless whether c++ is supposed to be used to link python.exe on >> Mac OS X or not, there is still a bug that needs fixing: Martin> Can you submit a patch? Apparently, configure determines that Martin> -Kthread is supported on your system. If it isn't, you should Martin> find out why the test testing for it succeeds. The -Kthread thing is just a warning. gcc/g++ complains but completes the command, exiting with a 0 status. I tried adding -Werror and -Wall to the command line but the exit status was still 0. I think you need different check than the usual command completion to determine whether -Kthread should be given or not. If you can suggest some ways to do this with configure macros I will take a stab at it, but I don't understand autoconf/configure well enough. I suspect doing something like c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option' is too fragile, but that may be the only sort of solution available. I took a quick look at a RH8 machine. Its gcc doesn't understand -Kthreads either. Maybe it's a safe assumption that if $CC == gcc -Kthreads should not be given. Skip