You're right, the environment variables weren't getting imported. So I just added it to my python code instead: import os; os.environ['CC'] = 'g++'; os.environ['CXX'] = 'g++'; os.environ['CPP'] = 'g++'; os.environ['LDSHARED'] = 'g++' I found that CC determined the 1st command and LDSHARED determined the second one (gcc vs. g++). But strangely enough, neither (CC=g++ and LDSHARED=g++) or (CC=g++ and LDSHARED=gcc) worked. But if I do (CC=gcc and LDSHARED=gcc) then manually redo the 2nd g++, then it works. See below... Seems to be some kind of linking issue... (Thanks)
python2.5 setup.py build --compiler=unix running build running build_ext building 'demo' extension creating build creating build/temp.linux-x86_64-2.5 g++ -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fpermissive -fPIC -I/tool/pandora64/.package/python-2.5/include/python2.5 -c demo.C -o build/temp.linux-x86_64-2.5/demo.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ creating build/lib.linux-x86_64-2.5 g++ build/temp.linux-x86_64-2.5/demo.o -o build/lib.linux-x86_64-2.5/demo.so /usr/lib/../lib64/crt1.o: In function `_start': /usr/lib/../lib64/crt1.o(.text+0x21): undefined reference to `main' build/temp.linux-x86_64-2.5/demo.o: In function `spam_system(_object*, _object*)': initdemo/demo.C:8: undefined reference to `PyArg_ParseTuple' initdemo/demo.C:11: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.5/demo.o: In function `initdemo': initdemo/demo.C:22: undefined reference to `Py_InitModule4_64'
collect2: ld returned 1 exit status error: command 'g++' failed with exit status 1
python2.5 setup.py build --compiler=unix running build running build_ext building 'demo' extension creating build creating build/temp.linux-x86_64-2.5 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fpermissive -fPIC -I/tool/pandora64/.package/python-2.5/include/python2.5 -c demo.C -o build/temp.linux-x86_64-2.5/demo.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ creating build/lib.linux-x86_64-2.5 g++ build/temp.linux-x86_64-2.5/demo.o -o build/lib.linux-x86_64-2.5/demo.so /usr/lib/../lib64/crt1.o: In function `_start': /usr/lib/../lib64/crt1.o(.text+0x21): undefined reference to `main' build/temp.linux-x86_64-2.5/demo.o: In function `spam_system(_object*, _object*)': initdemo/demo.C:8: undefined reference to `PyArg_ParseTuple' initdemo/demo.C:11: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.5/demo.o: In function `initdemo': initdemo/demo.C:22: undefined reference to `Py_InitModule4_64'
collect2: ld returned 1 exit status error: command 'g++' failed with exit status 1
python2.5 setup.py build --compiler=unix running build running build_ext building 'demo' extension creating build creating build/temp.linux-x86_64-2.5 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wstrict-prototypes -fpermissive -fPIC -I/tool/pandora64/.package/python-2.5/include/python2.5 -c demo.C -o build/temp.linux-x86_64-2.5/demo.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ creating build/lib.linux-x86_64-2.5 gcc -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o build/lib.linux-x86_64-2.5/demo.so g++ -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o build/lib.linux-x86_64-2.5/demo.so echo "/cheer - that works - I can import the module in python"
-----Original Message----- From: Phillip J. Eby [mailto:pje@telecommunity.com] Sent: Wednesday, May 16, 2007 1:06 PM To: Mowry, Peter; Matt Good Cc: distutils-sig@python.org; David Arnold Subject: RE: [Distutils] setup.py demo.C build (gcc vs. g++) (distutils) At 12:19 PM 5/16/2007 -0500, Mowry, Peter wrote:
echo $CC $CPP $CXX $LDSHARED g++ g++ g++ g++
Try this instead: python2.5 -c "import os; print os.environ['CXX']" Does it display the same thing?