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

[Phillip J. Eby]

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.html>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.