how to set cc correctly?

how could one set the compiler correctly? http://opencsw has a setuptools package, which does not use the cc in the path, but in /opt/studio/SOS11/SUNWspro/bin/cc so the following happens: # CC=/opt/SUNWspro/bin/cc easy_install genshi Searching for genshi Reading http://pypi.python.org/simple/genshi/ Reading http://genshi.edgewall.org/ Reading http://genshi.edgewall.org/wiki/Download Best match: Genshi 0.5.1 Downloading http://ftp.edgewall.com/pub/genshi/Genshi-0.5.1.zip Processing Genshi-0.5.1.zip Running Genshi-0.5.1/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-7yiT65/Genshi-0.5.1/egg-dist-tmp-Cp42JQ warning: no previously-included files found matching 'doc/ 2000ft.graffle' warning: no previously-included files matching '*' found under directory 'doc/logo.lineform' unable to execute /opt/studio/SOS11/SUNWspro/bin/cc: No such file or directory ********************************************************************** WARNING: An optional C extension could not be compiled, speedups will not be available. ********************************************************************** Adding Genshi 0.5.1 to easy-install.pth file Installed /opt/csw/lib/python2.6/site-packages/Genshi-0.5.1-py2.6- solaris-2.10-sun4v.egg Processing dependencies for genshi Finished processing dependencies for genshi

On Sun, Apr 26, 2009 at 9:39 PM, rupert.thurner <rupert.thurner@gmail.com> wrote:
how could one set the compiler correctly? http://opencsw has a setuptools package, which does not use the cc in the path, but in /opt/studio/SOS11/SUNWspro/bin/cc
so the following happens:
# CC=/opt/SUNWspro/bin/cc easy_install genshi Searching for genshi Reading http://pypi.python.org/simple/genshi/ Reading http://genshi.edgewall.org/ Reading http://genshi.edgewall.org/wiki/Download Best match: Genshi 0.5.1 Downloading http://ftp.edgewall.com/pub/genshi/Genshi-0.5.1.zip Processing Genshi-0.5.1.zip Running Genshi-0.5.1/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-7yiT65/Genshi-0.5.1/egg-dist-tmp-Cp42JQ warning: no previously-included files found matching 'doc/ 2000ft.graffle' warning: no previously-included files matching '*' found under directory 'doc/logo.lineform' unable to execute /opt/studio/SOS11/SUNWspro/bin/cc: No such file or directory
I am not sur to understand what you are trying to achieve. This indicates your environment variable CC was properly set and sent to the compiler. Are you sure "/opt/studio/SOS11/SUNWspro/bin/cc" exists and is executable ? If cc is located somewhere else, try: # CC=/its/here/cc easy_install genshi If you don't provide any CC, it will use the one defined in the Makefile of your Python installation. Tarek -- Tarek Ziadé | http://ziade.org

Tarek Ziadé wrote:
I am not sur to understand what you are trying to achieve.
This indicates your environment variable CC was properly set and sent to the compiler.
I don't think it does: the user requires /opt/SUNWspro/bin/cc as a C compiler, and easy_install uses /opt/studio/SOS11/SUNWspro/bin/cc which are different compilers, unless one is a softlink to the other. cheers, David

On Tue, Apr 28, 2009 at 5:23 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Tarek Ziadé wrote:
I am not sur to understand what you are trying to achieve.
This indicates your environment variable CC was properly set and sent to the compiler.
I don't think it does: the user requires /opt/SUNWspro/bin/cc as a C compiler, and easy_install uses /opt/studio/SOS11/SUNWspro/bin/cc which are different compilers, unless one is a softlink to the other.
Oops, correct, I didn't notice there were different. Rupert, can you try downloading that package, uncompress it and run : # CC=/opt/SUNWspro/bin/cc python setup.py install If this fails too, there's a problem in Distutils.sysconfig.customize_compiler we need to look at. (basically, it looks at os.environ if your compiler type is "unix" and not mingw or bcpp, or msvc etc..) If it works, the problem is on easy_install itself.
cheers,
David
-- Tarek Ziadé | http://ziade.org

On Apr 28, 7:39 am, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Tue, Apr 28, 2009 at 5:23 AM, David Cournapeau
<da...@ar.media.kyoto-u.ac.jp> wrote:
Tarek Ziadé wrote:
I am not sur to understand what you are trying to achieve.
This indicates your environment variable CC was properly set and sent to the compiler.
I don't think it does: the user requires /opt/SUNWspro/bin/cc as a C compiler, and easy_install uses /opt/studio/SOS11/SUNWspro/bin/cc which are different compilers, unless one is a softlink to the other.
Oops, correct, I didn't notice there were different.
Rupert, can you try downloading that package, uncompress it and run :
# CC=/opt/SUNWspro/bin/cc python setup.py install
If this fails too, there's a problem in Distutils.sysconfig.customize_compiler we need to look at. (basically, it looks at os.environ if your compiler type is "unix" and not mingw or bcpp, or msvc etc..)
If it works, the problem is on easy_install itself.
you are right! it works, nearly, but this might be a reportlab problem: # CC=/cs/SUNWspro/bin/cc python setup.py install ################################################ #Attempting install of _rl_accel, sgmlop & pyHnj #extensions from '/tmp/ReportLab_2_3/src/rl_addons/rl_accel' ################################################ ################################################ #Attempting install of _renderPM #extensions from '/tmp/ReportLab_2_3/src/rl_addons/renderPM' # installing with freetype version 21 ################################################ running install running build running build_py copying src/reportlab/lib/hyphen.mashed -> build/lib.solaris-2.10- sun4v-2.6/reportlab/lib running build_clib building '_renderPM_libart' library /cs/SUNWspro/bin/cc -DNDEBUG -O -xO3 -xarch=v8 -DLIBART_COMPILATION - DWORDS_BIGENDIAN -I/tmp/ReportLab_2_3/src/rl_addons/renderPM -I/tmp/ ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl -c /tmp/ReportLab_2_3/ src/rl_addons/renderPM/libart_lgpl/art_uta.c -o build/ temp.solaris-2.10-sun4v-2.6/tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.o ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 29: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 31: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 33: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 38: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 39: syntax error before or at: ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 81: type specifier can not be used as array size expression qualifier "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 82: warning: no explicit type given "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 83: warning: old-style declaration or incorrect type for: art_uta_free "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 88: cannot recover from previous errors cc: acomp failed for /tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.c error: command '/opt/SUNWspro/bin/cc' failed with exit status 2

could we patch setuptools somehow? where would be the source code? On May 12, 1:08 pm, "rupert.thurner" <rupert.thur...@gmail.com> wrote:
On Apr 28, 7:39 am, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Tue, Apr 28, 2009 at 5:23 AM, David Cournapeau
<da...@ar.media.kyoto-u.ac.jp> wrote:
Tarek Ziadé wrote:
I am not sur to understand what you are trying to achieve.
This indicates your environment variable CC was properly set and sent to the compiler.
I don't think it does: the user requires /opt/SUNWspro/bin/cc as a C compiler, and easy_install uses /opt/studio/SOS11/SUNWspro/bin/cc which are different compilers, unless one is a softlink to the other.
Oops, correct, I didn't notice there were different.
Rupert, can you try downloading that package, uncompress it and run :
# CC=/opt/SUNWspro/bin/cc python setup.py install
If this fails too, there's a problem in Distutils.sysconfig.customize_compiler we need to look at. (basically, it looks at os.environ if your compiler type is "unix" and not mingw or bcpp, or msvc etc..)
If it works, the problem is on easy_install itself.
you are right! it works, nearly, but this might be a reportlab problem:
# CC=/cs/SUNWspro/bin/cc python setup.py install ################################################ #Attempting install of _rl_accel, sgmlop & pyHnj #extensions from '/tmp/ReportLab_2_3/src/rl_addons/rl_accel' ################################################ ################################################ #Attempting install of _renderPM #extensions from '/tmp/ReportLab_2_3/src/rl_addons/renderPM' # installing with freetype version 21 ################################################ running install running build running build_py copying src/reportlab/lib/hyphen.mashed -> build/lib.solaris-2.10- sun4v-2.6/reportlab/lib running build_clib building '_renderPM_libart' library /cs/SUNWspro/bin/cc -DNDEBUG -O -xO3 -xarch=v8 -DLIBART_COMPILATION - DWORDS_BIGENDIAN -I/tmp/ReportLab_2_3/src/rl_addons/renderPM -I/tmp/ ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl -c /tmp/ReportLab_2_3/ src/rl_addons/renderPM/libart_lgpl/art_uta.c -o build/ temp.solaris-2.10-sun4v-2.6/tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.o ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 29: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 31: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 33: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 38: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 39: syntax error before or at: ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 81: type specifier can not be used as array size expression qualifier "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 82: warning: no explicit type given "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 83: warning: old-style declaration or incorrect type for: art_uta_free "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 88: cannot recover from previous errors cc: acomp failed for /tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.c error: command '/opt/SUNWspro/bin/cc' failed with exit status 2
_______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

On Fri, May 22, 2009 at 3:05 PM, rupert.thurner <rupert.thurner@gmail.com> wrote:
could we patch setuptools somehow? where would be the source code?
- the code is here : http://svn.python.org/view/sandbox/trunk/setuptools/ - the bug tracker is here: http://bugs.python.org/setuptools/ - the maintainer is : Phillip Eby

we now face the same issue with pil-1.1.6. it compiles correctly, but at the end it somehow tries again to call the default compiler the creator of the easy_install package used. is this set somewhere, or where is this set? we have it here: /opt/SUNWspro/bin/cc while the default is: /opt/studio/SOS11/SUNWspro/bin/cc # CC=/opt/SUNWspro/bin/cc python setup.py build running build running build_py running build_ext building '_imaging' extension /opt/studio/SOS11/SUNWspro/bin/cc -G build/temp.solaris-2.10-sun4v-2.6/ _imaging.o build/temp.solaris-2.10-sun4v-2.6/decode.o build/ temp.solaris-2.10-sun4v-2.6/encode.o build/temp.solaris-2.10-sun4v-2.6/ map.o build/temp.solaris-2.10-sun4v-2.6/display.o build/ temp.solaris-2.10-sun4v-2.6/outline.o build/temp.solaris-2.10- sun4v-2.6/path.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Access.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Antialias.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Bands.o build/temp.solaris-2.10- sun4v-2.6/libImaging/BitDecode.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/Blend.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ Chops.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Convert.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/ConvertYCbCr.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Copy.o build/temp.solaris-2.10- sun4v-2.6/libImaging/Crc32.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/Crop.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Dib.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Draw.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Effects.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/EpsEncode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/File.o build/temp.solaris-2.10- sun4v-2.6/libImaging/Fill.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/Filter.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ FliDecode.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Geometry.o build/temp.solaris-2.10-sun4v-2.6/libImaging/GetBBox.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/GifDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/GifEncode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/HexDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Histo.o build/temp.solaris-2.10- sun4v-2.6/libImaging/JpegDecode.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/JpegEncode.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ LzwDecode.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Matrix.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ModeFilter.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/MspDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Negative.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Offset.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Pack.o build/temp.solaris-2.10- sun4v-2.6/libImaging/PackDecode.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/Palette.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ Paste.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Quant.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/QuantHash.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/QuantHeap.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/PcdDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/PcxDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/PcxEncode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Point.o build/temp.solaris-2.10- sun4v-2.6/libImaging/RankFilter.o build/temp.solaris-2.10-sun4v-2.6/ libImaging/RawDecode.o build/temp.solaris-2.10-sun4v-2.6/libImaging/ RawEncode.o build/temp.solaris-2.10-sun4v-2.6/libImaging/Storage.o build/temp.solaris-2.10-sun4v-2.6/libImaging/SunRleDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/TgaRleDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/Unpack.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/UnpackYCC.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/XbmDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/XbmEncode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/ZipDecode.o build/ temp.solaris-2.10-sun4v-2.6/libImaging/ZipEncode.o -L/usr/local/lib -L/ opt/csw/lib -L/usr/lib -ljpeg -lz -lpython2.6 -o build/ lib.solaris-2.10-sun4v-2.6/_imaging.so unable to execute /opt/studio/SOS11/SUNWspro/bin/cc: No such file or directory error: command '/opt/studio/SOS11/SUNWspro/bin/cc' failed with exit status 1 On May 12, 1:08 pm, "rupert.thurner" <rupert.thur...@gmail.com> wrote:
On Apr 28, 7:39 am, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Tue, Apr 28, 2009 at 5:23 AM, David Cournapeau
<da...@ar.media.kyoto-u.ac.jp> wrote:
Tarek Ziadé wrote:
I am not sur to understand what you are trying to achieve.
This indicates your environment variable CC was properly set and sent to the compiler.
I don't think it does: the user requires /opt/SUNWspro/bin/cc as a C compiler, and easy_install uses /opt/studio/SOS11/SUNWspro/bin/cc which are different compilers, unless one is a softlink to the other.
Oops, correct, I didn't notice there were different.
Rupert, can you try downloading that package, uncompress it and run :
# CC=/opt/SUNWspro/bin/cc python setup.py install
If this fails too, there's a problem in Distutils.sysconfig.customize_compiler we need to look at. (basically, it looks at os.environ if your compiler type is "unix" and not mingw or bcpp, or msvc etc..)
If it works, the problem is on easy_install itself.
you are right! it works, nearly, but this might be a reportlab problem:
# CC=/cs/SUNWspro/bin/cc python setup.py install ################################################ #Attempting install of _rl_accel, sgmlop & pyHnj #extensions from '/tmp/ReportLab_2_3/src/rl_addons/rl_accel' ################################################ ################################################ #Attempting install of _renderPM #extensions from '/tmp/ReportLab_2_3/src/rl_addons/renderPM' # installing with freetype version 21 ################################################ running install running build running build_py copying src/reportlab/lib/hyphen.mashed -> build/lib.solaris-2.10- sun4v-2.6/reportlab/lib running build_clib building '_renderPM_libart' library /cs/SUNWspro/bin/cc -DNDEBUG -O -xO3 -xarch=v8 -DLIBART_COMPILATION - DWORDS_BIGENDIAN -I/tmp/ReportLab_2_3/src/rl_addons/renderPM -I/tmp/ ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl -c /tmp/ReportLab_2_3/ src/rl_addons/renderPM/libart_lgpl/art_uta.c -o build/ temp.solaris-2.10-sun4v-2.6/tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.o ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 29: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 31: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 33: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 38: warning: invalid white space character in directive "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.h", line 39: syntax error before or at: ... "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 81: type specifier can not be used as array size expression qualifier "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 82: warning: no explicit type given "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 83: warning: old-style declaration or incorrect type for: art_uta_free "/tmp/ReportLab_2_3/src/rl_addons/renderPM/libart_lgpl/art_uta.c", line 88: cannot recover from previous errors cc: acomp failed for /tmp/ReportLab_2_3/src/rl_addons/renderPM/ libart_lgpl/art_uta.c error: command '/opt/SUNWspro/bin/cc' failed with exit status 2
_______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

On Fri, May 22, 2009 at 3:11 PM, rupert.thurner <rupert.thurner@gmail.com> wrote:
we now face the same issue with pil-1.1.6. it compiles correctly, but at the end it somehow tries again to call the default compiler the creator of the easy_install package used. is this set somewhere, or where is this set?
we have it here: /opt/SUNWspro/bin/cc while the default is: /opt/studio/SOS11/SUNWspro/bin/cc
# CC=/opt/SUNWspro/bin/cc python setup.py build running build running build_py running build_ext
The build_ext command creates a new compiler instance, then call customize_compiler on it, that is supposed to use the CC set in the environment when you are under a unix-like system. What you can do to find out what is going on is to set a pdb in distutils.command.build_ext in the run command, to see how customize_compiler acts in your environment. If you don't know how to use pdb, check http://docs.python.org/library/pdb.html Regards Tarek -- Tarek Ziadé | http://ziade.org

are you sure you are not violating something here? the documentation on http://docs.python.org/distutils/apiref.html says: " distutils.sysconfig.customize_compiler(compiler)¶ Do any platform-specific customization of a distutils.ccompiler.CCompiler instance. This function is only needed on Unix at this time, but should be called consistently to support forward-compatibility. It inserts the information that varies across Unix flavors and is stored in Python’s Makefile. This information includes the selected compiler, compiler and linker options, and the extension used by the linker for shared objects. This function is even more special-purpose, and should only be used from Python’s own build procedures. " the packager of our operating systems python had the compiler in /opt/ studio/... but we do not. rupert. On May 22, 3:19 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 3:11 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
we now face the same issue with pil-1.1.6. it compiles correctly, but at the end it somehow tries again to call the default compiler the creator of the easy_install package used. is this set somewhere, or where is this set?
we have it here: /opt/SUNWspro/bin/cc while the default is: /opt/studio/SOS11/SUNWspro/bin/cc
# CC=/opt/SUNWspro/bin/cc python setup.py build running build running build_py running build_ext
The build_ext command creates a new compiler instance, then call customize_compiler on it, that is supposed to use the CC set in the environment when you are under a unix-like system.
What you can do to find out what is going on is to set a pdb in distutils.command.build_ext in the run command, to see how customize_compiler acts in your environment.
If you don't know how to use pdb, checkhttp://docs.python.org/library/pdb.html
Regards Tarek
-- Tarek Ziadé |http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

On Fri, May 22, 2009 at 3:36 PM, rupert.thurner <rupert.thurner@gmail.com> wrote:
are you sure you are not violating something here?
What do you mean ?
the packager of our operating systems python had the compiler in /opt/ studio/... but we do not.
build_ext will pick the CC it finds in the Makefile but overrides it if one is set in os.environ['CC'] I am unable to reproduce your problem here, so you should check as I previously said, what is happening when you call build_ext, to understand why your CC isn't picked. Regards Tarek -- Tarek Ziadé | http://ziade.org

On Fri, May 22, 2009 at 3:36 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
are you sure you are not violating something here?
What do you mean ?
On May 22, 3:41 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote: the "This function is even more special-purpose, and should only be used from Python’s own build procedures. "
the packager of our operating systems python had the compiler in /opt/ studio/... but we do not.
build_ext will pick the CC it finds in the Makefile but overrides it if one is set in os.environ['CC']
i cannot find it in the code ... but it seems to work on the top level but is not passed on, so i wonder where in the code this is ? # ggrep -R os.environ /opt/csw/lib/python2.6/site-packages/setuptools/ * /opt/csw/lib/python2.6/site-packages/setuptools/command/ easy_install.py: PYTHONPATH = os.environ.get ('PYTHONPATH','').split(os.pathsep) /opt/csw/lib/python2.6/site-packages/setuptools/command/ easy_install.py: self.install_dir, os.environ.get ('PYTHONPATH','') /opt/csw/lib/python2.6/site-packages/setuptools/command/ easy_install.py: sitedirs = filter(None,os.environ.get ('PYTHONPATH','').split(os.pathsep)) /opt/csw/lib/python2.6/site-packages/setuptools/command/ easy_install.py: home = os.environ.get('HOME') /opt/csw/lib/python2.6/site-packages/setuptools/command/ upload.py: if os.environ.has_key('HOME'): /opt/csw/lib/python2.6/site-packages/setuptools/command/ upload.py: rc = os.path.join(os.environ['HOME'], '.pypirc')
I am unable to reproduce your problem here, so you should check as I previously said, what is happening when you call build_ext, to understand why your CC isn't picked.
me and python programming :) i did python -m pdb setup.py build # python -m pdb setup.py build
/tmp/Imaging-1.1.6/setup.py(9)<module>() -> import glob, os, re, struct, string, sys (Pdb) os.environ['CC'] *** NameError: name 'os' is not defined (Pdb) import os (Pdb) os.environ['CC'] '/opt/SUNWspro/bin/cc' (Pdb) b distutils.command.build_ext *** The specified object 'distutils.command.build_ext' is not a function or was not found along sys.path.
rupert.

On Fri, May 22, 2009 at 4:07 PM, rupert.thurner <rupert.thurner@gmail.com> wrote:
On Fri, May 22, 2009 at 3:36 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
are you sure you are not violating something here?
What do you mean ?
On May 22, 3:41 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote: the "This function is even more special-purpose, and should only be used from Python’s own build procedures. "
As a matter of fact, Python uses build_ext when it's built. What the documentation means here is that you should not use customize_compiler in your code, but through build_ext and a few other commands in Python's distutils. I agree it's not very clear though, and that it should be made private with a "_"
the packager of our operating systems python had the compiler in /opt/ studio/... but we do not.
build_ext will pick the CC it finds in the Makefile but overrides it if one is set in os.environ['CC']
i cannot find it in the code ... but it seems to work on the top level but is not passed on, so i wonder where in the code this is ?
It's in distutils code, not setuptools. Setuptools is a layer on the top of distutils.

ah ... found it. but i do not make any progress with debugging. somehow it seems to use the correct compiler while compiling but not when linking. /cs/SUNWspro/bin/cc -DNDEBUG -O -xO3 -xarch=v8 -DHAVE_LIBJPEG - DHAVE_LIBZ -DWORDS_BIGENDIAN -I/opt/csw/include/freetype2 -IlibImaging -I/opt/csw/include -I/usr/include -I/opt/csw/include/python2.6 -c libImaging/ZipEncode.c -o build/temp.solaris-2.10-sun4v-2.6/libImaging/ ZipEncode.o /opt/studio/SOS11/SUNWspro/bin/cc -G build/temp.solaris-2.10-sun4v-2.6/ _imaging.o build/temp.solaris-2.10-sun4v-2.6/decode.o <cut> ... -L/usr/lib -ljpeg -lz -lpython2.6 -o build/lib.solaris-2.10-sun4v-2.6/ _imaging.so rupert. On May 22, 4:13 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 4:07 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
On May 22, 3:41 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 3:36 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
are you sure you are not violating something here?
What do you mean ? the "This function is even more special-purpose, and should only be used from Python’s own build procedures. "
As a matter of fact, Python uses build_ext when it's built. What the documentation means here is that you should not use customize_compiler in your code, but through build_ext and a few other commands in Python's distutils.
I agree it's not very clear though, and that it should be made private with a "_"
the packager of our operating systems python had the compiler in /opt/ studio/... but we do not.
build_ext will pick the CC it finds in the Makefile but overrides it if one is set in os.environ['CC']
i cannot find it in the code ... but it seems to work on the top level but is not passed on, so i wonder where in the code this is ?
It's in distutils code, not setuptools. Setuptools is a layer on the top of distutils. _______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

# python Python 2.6.1 (r261:67515, Mar 2 2009, 14:14:28) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. from distutils.ccompiler import new_compiler compiler = new_compiler(None,None,None,None) compiler.compiler_type='unix' from distutils.sysconfig import customize_compiler customize_compiler(compiler) compiler.linker_so ['/opt/studio/SOS11/SUNWspro/bin/cc', '-G'] compiler.compiler ['/opt/SUNWspro/bin/cc', '-DNDEBUG', '-O'] export LDSHARED=/opt/SUNWspro/bin/cc python
from distutils.ccompiler import new_compiler compiler = new_compiler(None,None,None,None) compiler.compiler_type='unix' from distutils.sysconfig import customize_compiler customize_compiler(compiler) compiler.linker_so ['/opt/SUNWspro/bin/cc']
and the option "-G" is gone ? export LDFLAGS=-G as well does the job. but i am wondering if all of this is the intention ? rupert. On May 22, 5:26 pm, "rupert.thurner" <rupert.thur...@gmail.com> wrote:
ah ... found it. but i do not make any progress with debugging. somehow it seems to use the correct compiler while compiling but not when linking.
/cs/SUNWspro/bin/cc -DNDEBUG -O -xO3 -xarch=v8 -DHAVE_LIBJPEG - DHAVE_LIBZ -DWORDS_BIGENDIAN -I/opt/csw/include/freetype2 -IlibImaging -I/opt/csw/include -I/usr/include -I/opt/csw/include/python2.6 -c libImaging/ZipEncode.c -o build/temp.solaris-2.10-sun4v-2.6/libImaging/ ZipEncode.o /opt/studio/SOS11/SUNWspro/bin/cc -G build/temp.solaris-2.10-sun4v-2.6/ _imaging.o build/temp.solaris-2.10-sun4v-2.6/decode.o <cut> ... -L/usr/lib -ljpeg -lz -lpython2.6 -o build/lib.solaris-2.10-sun4v-2.6/ _imaging.so
rupert.
On May 22, 4:13 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 4:07 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
On May 22, 3:41 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 3:36 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
are you sure you are not violating something here?
What do you mean ? the "This function is even more special-purpose, and should only be used from Python’s own build procedures. "
As a matter of fact, Python uses build_ext when it's built. What the documentation means here is that you should not use customize_compiler in your code, but through build_ext and a few other commands in Python's distutils.
I agree it's not very clear though, and that it should be made private with a "_"
the packager of our operating systems python had the compiler in /opt/ studio/... but we do not.
build_ext will pick the CC it finds in the Makefile but overrides it if one is set in os.environ['CC']
i cannot find it in the code ... but it seems to work on the top level but is not passed on, so i wonder where in the code this is ?
It's in distutils code, not setuptools. Setuptools is a layer on the top of distutils. _______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

i also filed a bug in opencsw to use a "standard compiler location" to avoid such issues in the future: http://opencsw.org/mantis/view.php?id=3682. rupert. On May 22, 3:19 pm, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
On Fri, May 22, 2009 at 3:11 PM, rupert.thurner
<rupert.thur...@gmail.com> wrote:
we now face the same issue with pil-1.1.6. it compiles correctly, but at the end it somehow tries again to call the default compiler the creator of the easy_install package used. is this set somewhere, or where is this set?
we have it here: /opt/SUNWspro/bin/cc while the default is: /opt/studio/SOS11/SUNWspro/bin/cc
# CC=/opt/SUNWspro/bin/cc python setup.py build running build running build_py running build_ext
The build_ext command creates a new compiler instance, then call customize_compiler on it, that is supposed to use the CC set in the environment when you are under a unix-like system.
What you can do to find out what is going on is to set a pdb in distutils.command.build_ext in the run command, to see how customize_compiler acts in your environment.
If you don't know how to use pdb, checkhttp://docs.python.org/library/pdb.html
Regards Tarek
-- Tarek Ziadé |http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-...@python.orghttp://mail.python.org/mailman/listinfo/distutils-sig
participants (3)
-
David Cournapeau
-
rupert.thurner
-
Tarek Ziadé