We Keep Coding

Install cx_oracle on solaris 11 sparc

Most of the cx_Oracle 5.2.1 version builds are for Windows and Linux. How do I install/get an install for a Solaris 11 Sparc?
I tried to install using the following: cx_Oracle-5.2.1.tar.gz from sourceforge.net
But resulted in the following error:
/tmp/cx_Oracle-5.2.1$ python setup.py build
running build
running build_ext
building 'cx_Oracle' extension
creating build
creating build/temp.solaris-2.11-sun4v.32bit-2.7-11g
cc -DNDEBUG -KPIC -DPIC -I/u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/public -I/usr/include/python2.7 -c cx_Oracle.c -o build/temp.solaris-2.11-sun4v.32bit-2.7-11g/cx_Oracle.o -DBUILD_VERSION=5.2.1
unable to execute 'cc': No such file or directory
error: command 'cc' failed with exit status 1
Please advise.

Oracle (nor Sun, for that matter) did not include a compiler in the Solaris OS installation image. The Solaris Studio compiler is available for download, and of course you can also go the GCC route (UNIX Packages web site offers installable packages of GCC and various libraries needed for dependences for a modest fee.)
The original post is quote old though, and the solution as of now is to simply install the cx_oracle package from the 11.3 or 11.4 IPS.

I do not know the exact reason for the error you are getting. It looks, however, like the "cc" compiler is not installed. You should be able to find that package and install it. Or you will need to adjust your configuration to use gcc instead. This link may help:
http://www.unix.com/solaris/114262-command-cc-failed-even-though-gcc-installed.html

Making Cython work with Python 3.4 on Anacondas, Windows 7 64-bit

I have just installed Python 3.4 on my Windows 7 64-bit machine, using Anaconda/Condas.
When I run the "hello world" cython example I get this error:
[py34] C:\Users\Jon\Documents\GitHub\CythonFunctions\cython_funcs>python setup.py build_ext --inplace
running build_ext
building 'cython_funcs.hello' extension
C:\Anaconda\envs\py34\MinGW\bin\gcc.exe -mdll -O -Wall -IC:\Anaconda\envs\py34\include -IC:\Anaconda\envs\py34\include -c hello.c -o build\temp.win-amd64-3.4\Release\hello.o
writing build\temp.win-amd64-3.4\Release\hello.def
C:\Anaconda\envs\py34\MinGW\bin\gcc.exe -shared -s build\temp.win-amd64-3.4\Release\hello.o build\temp.win-amd64-3.4\Release\hello.def -LC:\Anaconda\envs\py34\libs -LC:\Anaconda\envs\py34\PCbuild\amd6
4 -lpython34 -lmsvcr100 -o C:\Users\Jon\Documents\GitHub\CythonFunctions\cython_funcs\cython_funcs\hello.pyd
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x314): undefined reference to `__imp__PyThreadState_Current'
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x493): undefined reference to `__imp__Py_NoneStruct'
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x97b): undefined reference to `__imp_PyExc_ImportError'
collect2.exe: error: ld returned 1 exit status
error: command 'C:\\Anaconda\\envs\\py34\\MinGW\\bin\\gcc.exe' failed with exit status 1
From searching stackoverflow and google, this error occurs when the gcc and python versions are not both either 32 bit or 64 bit.
I have checked that my Python is 64 bit. The MinGW that I have, as can be seen from the path below, was part of my Python installation. How can I check if it is 64 bit or not? Or could this error be due to something else?
Update:
Strangely, the Ipython cythonmagic command here works fine:
http://docs.cython.org/src/quickstart/build.html?highlight=cythonmagic

One way would be to conda remove libpython (this will cause distutils to not use mingw), and install Visual Studio 2010, and use that to compile.

Your gcc line is missing a define: -DMS_WIN64. Anaconda (I presume) have modified the file cygwinccompiler.py in Lib/distutils of 2.7 envs, but this modification is not present in the distutils of the 3.4 env. I was getting different errors to yours, but this change fixed my setup.

I ran into a similar problem with Anaconda but it worked when I stopped trying to compile in the py34 directory. Instead put your helloworld.pyx file (make sure you change it to that extension .pyx as well) in the Anaconda3 folder along with the setup.py and when you compile make sure you are in the Anaconda3 folder as well so C:\Anaconda3 python setup.py build_ext --inplace. If memory serves this ran just fine.

This might work for linking problems (to be done in a temporary directory; copy instead of cp if not in a msys2 environment)
gendef c:/Windows/System32/python34.dll
dlltool -U -d python34.def -l libpython34.dll.a
cp libpython34.dll.a c:/Python34/libs
If gendef is unable to access python34.dll, it can be copied using windows explorer before gendef command.
gendef is available at least with mingw-w64 packages.

Undefined symbol when importing Python Sybase module on OSX 10.6

I'm trying to get the python-sybase module working on OSX 10.6, but I've run into a bit of a snag.
When I do
import Sybase
I get
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "Sybase.py", line 15, in <module>
from sybasect import *
ImportError: dlopen(/Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so, 2): Symbol not found: _blk_alloc
Referenced from: /Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/python_sybase-0.40pre2-py2.6-macosx-10.6-universal.egg/sybasect.so
I took a look at sybasect.so, and sure enough, _blk_alloc is undefined. The function is located in Sybase's sybblk.dylib, which is installed, and its containing directory is in LD_LIBRARY_PATH.
When I compiled python-sybase using python setup.py build, the gcc command appears to find all of the right libs correctly, but for some reason those libs don't appear to be linked after installing sybasect.so to the Python module dir.
The gcc command is
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc -arch x86_64 build/temp.macosx-10.6-universal-2.6/blk.o build/temp.macosx-10.6-universal-2.6/databuf.o build/temp.macosx-10.6-universal-2.6/cmd.o build/temp.macosx-10.6-universal-2.6/conn.o build/temp.macosx-10.6-universal-2.6/ctx.o build/temp.macosx-10.6-universal-2.6/datafmt.o build/temp.macosx-10.6-universal-2.6/iodesc.o build/temp.macosx-10.6-universal-2.6/locale.o build/temp.macosx-10.6-universal-2.6/msgs.o build/temp.macosx-10.6-universal-2.6/numeric.o build/temp.macosx-10.6-universal-2.6/money.o build/temp.macosx-10.6-universal-2.6/datetime.o build/temp.macosx-10.6-universal-2.6/date.o build/temp.macosx-10.6-universal-2.6/sybasect.o -L/Applications/Sybase/System/OCS-15_0/lib -lsybblk -lsybct -lsybcs -lsybtcl -lsybcomn -lsybintl -lsybunic -o build/lib.macosx-10.6-universal-2.6/sybasect.so
The -L/Applications/Sybase/System/OCS-15_0/lib location is correct, and that folder contains all of the right .dylib's.
When I run otool the output is:
$ otool -L build/lib.macosx-10.6-universal-2.6/sybasect.so
build/lib.macosx-10.6-universal-2.6/sybasect.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
I was expecting to see the Sybase libs in there.
I'm a little new to linking on Mac. How do I ensure that sybasect.so references the Sybase libs?

Fixed it.
The problem was that the various Sybase libraries I was linking to were 32-bit only, but I was running Python in 64 bit mode. The fix was just running python in 32-bit mode.
I used the command defaults write com.apple.versioner.python Prefer-32-Bit -bool yes since I don't have any particular need for 64 bit mode.

Compiling with cython and mingw produces gcc: error: unrecognized command line option '-mno-cygwin'

I'm trying to compile a python extension with cython in win 7 64-bit using mingw (64-bit).
I'm working with Python 2.6 (Active Python 2.6.6) and with the adequate distutils.cfg file (setting mingw as the compiler)
When executing
> C:\Python26\programas\Cython>python setup.py build_ext --inplace
I get an error saying that gcc has not an -mno-cygwin option:
> C:\Python26\programas\Cython>python setup.py build_ext --inplace
running build_ext
skipping 'hello2.c' Cython extension (up-to-date)
building 'hello2' extension
C:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python26\include -IC:\Python26\PC -c hello2.c -o build\temp.win-amd64-2.6\Release\hello2.o
gcc: error: unrecognized command line option '-mno-cygwin'
error: command 'gcc' failed with exit status 1
gcc is:
C:\>gcc --version
gcc (GCC) 4.7.0 20110430 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
How could I fix it?

It sounds like GCC 4.7.0 has finally removed the deprecated -mno-cygwin option, but distutils has not yet caught up with it. Either install a slightly older version of MinGW, or edit distutils\cygwinccompiler.py in your Python directory to remove all instances of -mno-cygwin.

During the process of solving these and the following problems I found, I wrote a recipe in this thread. I reproduce it here in case it could be of utility for others:
Step by step recipe to compile 64-bit cython extensions with python
2.6.6 with mingw compiler in win 7 64-bit
Install mingw compiler
1) Install tdm64-gcc-4.5.2.exe for 64-bit compilation
Apply patch to python.h
2) Modify python.h in C:\python26\include as indicated in
http://bugs.python.org/file12411/mingw-w64.patch
Modify distutils
Edit 2013: Note than in python 2.7.6 and 3.3.3 -mno-cygwin has been finally removed so step 3 can be skipped.
3) Eliminate all the parameters -mno-cygwin fom the call to gcc in the
Mingw32CCompiler class in Python26\Lib\distutils\cygwinccompiler.py
4) In the same module, modify get_msvcr() to return an empty list
instead of ['msvcr90'] when msc_ver == '1500' .
Produce the libpython26.a file (not included in 64 bit python)
Edit 2013: the following steps 5-10 can be skipped by downloading and installing libpython26.a from gohlke.
5) Obtain gendef.exe from mingw-w64-bin_x86_64-
mingw_20101003_sezero.zip
(gendef.exe is not available in the tmd64 distribution. Another
solution is to compile gendef from source...)
6) Copy python26.dll (located at C\windows\system32) to the user
directory (C:\Users\myname)
7) Produce the python26.def file with:
gendef.exe C:\Users\myname\python26.dll
8) Move the python.def file produced (located in the folder from where
gendef was executed) to the user directory
9) Produce the libpython.a with:
dlltool -v --dllname python26.dll --def C:\Users\myname
\python26.def --output-lib C:\Users\myname\libpython26.a
10) Move the created libpython26.a to C:\Python26\libs
Produce your .pyd extension
11) Create a test hello.pyx file and a setup.py file as indicated in
cython tutorial (http://docs.cython.org/src/quickstart/build.html)
12) Compile with
python setup.py build_ext --inplace
Done!

This bug has now been fixed in Python 2.7.6 release candidate 1.
The patching commit is here.
The resolved issue tracker thread is here.

Try this . It really works for the error
https://github.com/develersrl/gccwinbinaries

Installing PIL on Snow Leopard -- NOTHING WORKS

I'm trying to install PIL on Snow Leopard, using Python 2.6.1, GCC 4.2.1, PIL 1.1.7, and have tried with both libjpeg6b and libjpeg7 -- nothing works. I've cleared out every trace of libjpeg/pil/zlib from fink, tried various compiler options, etc. and used http://jetfar.com/libjpeg-and-python-imaging-pil-on-snow-leopard/ and http:// www.brambraakman.com/blog/comments/installing_pil_in_snow_leopard_jpeg_resync_to_restart_error/ (not a link because StOv only lets me post one...)
4 bits of potentially useful information:
OTOOL does not show libjpeg as a dependency
otool -L /Library/Python/2.6/site-packages/PIL/_imaging.so
/Library/Python/2.6/site-packages/PIL/_imaging.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
I get these weird compiler messages
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tcl: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/sw/include/freetype2 -I/sw/include -I/opt/local/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include -I/usr/local/include -I/usr/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c Tk/tkImaging.c -o build/temp.macosx-10.6-universal-2.6/Tk/tkImaging.o -framework Tcl -framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
from Tk/tkImaging.c:51:
selftest.py fails because of _imagingmath (after I used the second link given above, before it too failed due to _imaging)
Themistocles:Imaging-1.1.7 me$ python selftest.py
Traceback (most recent call last):
File "selftest.py", line 11, in <module>
from PIL import ImageMath
File "./PIL/ImageMath.py", line 19, in <module>
import _imagingmath
ImportError: No module named _imagingmath
Anything but selftest.py fails because of _imaging
>>> import _imaging
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Python/2.6/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Python/2.6/site-packages/PIL/_imaging.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/PIL/_imaging.so
Please, please help! This is getting ridiculous. I'd even be happy to be able to compile PIL sans jpeg support at this point!

I recently wrote an article on how to get PIL, django, libjpeg to work nicely alongside Snow Leopard
http://appelfreelance.com/2010/06/libjpeg-pil-snow-leopard-python2-6-_jpeg_resync_to_restart/
I'll copy it in here for you too.
If you don’t have this download it first.
http://www.ijg.org/files/jpegsrc.v7.tar.gz
go into your shell environment and untar by running the following
tar -zxvf jpegsrc.v7.tar.gz
cd jpeg-7
then run
sudo make clean
sudo CC="gcc -arch i386”"./configure --enable-shared --enable-static
sudo make
sudo make install
Next get PIL and untar it
http://effbot.org/downloads/Imaging-1.1.6.tar.gz
tar -zxvf Imaging-1.1.6.tar.gz
cd Imaging-1.1.6
If you already have PIL I would recommend running
sudo rm -Rf build
to clean any existing builds, this has caused me loads of errors and gray hairs!
in your settings.py file run find JPEG_ROOT
amend it so it looks as follows
JPEG_ROOT = libinclude(“/usr/local”)
Next move onto the build
sudo python setup.py build
if libjpeg is successfully installed you should be able to run python selftest.py without any errors relating to “jpeg”
sudo python setup.py install
if all has worked successfully you should be able to enter your python interpreter by executing python in your command line and also do the following:
import PIL
import Image
import _imaging
without any errors.
Just to triple check I have a simple jpeg on my desktop.
image = Image.open(“/Users/MyName/Desktop/myimage.jpeg”)
image.save(“/Users/MyName/Desktop/test.jpeg”)
should work without errors

Download macport:
http://www.macports.org/install.php
Then use it for pil:
http://trac.macports.org/browser/trunk/dports/python/py-pil/Portfile
I also had a lot of trouble with this, but port managed.

I've always gotten several screens worth of gcc errors when trying to install PIL. At some point I got something working (perhaps via MacPorts), so now my solution is to copy it to the appropriate site-packages (e.g. inside a new virtualenv).
I just posted it here: http://blogmaker.com/PIL-1.1.6-for-MacOSX-10.5-Leopard.zip
Works for me; I have no idea whether it will work for anyone else! Feel free to contact me with suggestions. And, let me know if there's a better place I should post it. PIL is both very cool and a royal hassle; it would be nice to have a definitive place for support. There are other PIL-related issues that I never solved.