[Distutils] setup.py demo.C build (gcc vs. g++) (distutils)

[Mowry, Peter]

set CC="g++"
set CC=g++
Neither of these work :-(

I also tried:
python2.5 setup.py demo.C build --compiler=g++

python2.5 setup.py demo.C build --help-compiler
gives bcpp, cygwin, emx, mingw32, msvc, mwerks, unix (g++ is not an
option)

Any other ideas?

--Thanks

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com] 
Sent: Tuesday, May 15, 2007 7:11 PM
To: Mowry, Peter; Matt Good
Cc: distutils-sig at python.org; David Arnold
Subject: Re: [Distutils] setup.py demo.C build (gcc vs. g++) (distutils)

At 06:11 PM 5/15/2007 -0500, Mowry, Peter wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/related;
>         boundary="----_=_NextPart_001_01C79746.62B92D4C";
>         type="multipart/alternative"
>
>Ever seen this error?
>
>Build Error Description:
>python2.5 setup.py demo.C build
>
>That creates a demo.so, and when I try to import it, it gives me the
error:
>ImportError: ./demo.so: undefined symbol: __gxx_personality_v0
>
>
>Hack to fix it:
>I found one single helpful post about this on google:
><http://www.intevation.de/pipermail/thuban-list/2003-September/000230.h
tml>http://www.intevation.de/pipermail/thuban-list/2003-September/000230
.html 
>suggests:
>
>Do the link step of gdalwarp manually by copying the commandline 
>printed by setup.py and replacing the gcc with g++
>So I tried this, and I saw that setup.py prints the following 2
commands:
>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
>gcc -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o 
>build/lib.linux-x86_64-2.5/demo.so
>
>Then I simply manually rerun just the second command with g++:
>g++ -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o 
>build/lib.linux-x86_64-2.5/demo.so
>
>And now the import works and so does the python spam_system() function.
>
>
>Non-Hack to fix it?:
>Is there a non-hack way to fix this?
>
>I've seen this question on the internet but no answers so far.  I 
>did check --help-compiler, and it only lists --compiler=unix, not 
>--compiler=g++ for ex.

I believe you can use the $CC environment variable, e.g.

    CC=g++ python setup.py whatever

should cause it to use g++ as the executable instead of gcc.