[cx-oracle-users] Running cx_Oracle w/ Python 2.6.6
Brought to you by:
atuining
From: <ejo...@ea...> - 2015-10-28 16:42:03
|
I was asking on Friday about trying to get cx_Oracle built with Python version 2.6.6. Thank you, Shai and Anthony for your responses. So, Anthony said this: > One other issue that should be considered: if you are trying to use a > cx_Oracle built with the Python 2.6 you downloaded and built, but using the > system wide Python you may run into the difficulty you experienced. If, > however, you make sure that you build Python with the same configuration as > the system wide Python you should be good. > > If you run the system wide Python and print the value of sys.maxunicode you > should get 1114111 and if you run the one you built then you should get > 65535 (a different value). > > The option you want to the configure command when building Python is > --enable-unicode=ucs4. > Once you have enabled that on your personally built Python and confirmed > that running both gives the same value for sys.maxunicode you should be > good to go. :-) > > And even though I don't personally use Python 2.6 or test with it, there > shouldn't be any difficulties with using it yet; if there are, let me know. It's not exactly clear but there is sort of an implication here that you can build cx_Oracle 5.2 with Python 2.7 but run it with Python 2.6.6. I'm not sure if that's really what was meant, but it does not work. I got my own 2.7.10 build configured with the ucs4 flag and got cx_Oracle's setup.py to generate cleanly. When I tried to use the .so created , the unicode error was gone but then I got this in its place: >>> import cx_Oracle Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: ./cx_Oracle.so: undefined symbol: PyCapsule_Import So, if using 5.2 built with 2.7.10 from 2.6.6 is what you meant, then I am letting you know that there is a problem with running that (or at least the 2.6.6 that I have). If that's not what you meant, then nevermind. ;) I decided to just back up to cx_Oracle 5.1.2, made my own custom build of python 2.6.6, "borrowed" its Include/ directory as I showed before, ran the gcc commands directly to generate the cx_Oracle.so. That then works with the system python 2.6.6! So, I am very thankful to have a module to be able to talk to Oracle with. I had used pyodbc to talk with MS SQL Server systems before, but for some reason I could never manage to get pyodbc to connect with this Oracle DB. Below is a couple of warnings (just FYI) from when I built 5.2 with my 2.7.10. They are just warnings, but its always nicer to get "warm fuzzies" as a user rather than "cold pricklies". I'm not sure if there is anything you can (or want to) change to make these warning going away, but here's the info in case you do: epjohn$ /home/epjohn/src/Python-2.7.10/python setup.py build running build running build_ext building 'cx_Oracle' extension creating build/temp.linux-x86_64-2.7-11g gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/software/app/oracle/product/11.2.0Qv2/rdbms/demo -I/software/app/oracle/product/11.2.0Qv2/rdbms/public -I/home/epjohn/src/Python-2.7.10/Include -I/home/epjohn/src/Python-2.7.10 -c cx_Oracle.c -o build/temp.linux-x86_64-2.7-11g/cx_Oracle.o -DBUILD_VERSION=5.2 In file included from /software/app/oracle/product/11.2.0Qv2/rdbms/public/oci.h:3045, from cx_Oracle.c:10: /software/app/oracle/product/11.2.0Qv2/rdbms/public/ociap.h:10795: warning: function declaration isn't a prototype /software/app/oracle/product/11.2.0Qv2/rdbms/public/ociap.h:10801: warning: function declaration isn't a prototype creating build/lib.linux-x86_64-2.7-11g gcc -pthread -shared build/temp.linux-x86_64-2.7-11g/cx_Oracle.o -L/software/app/oracle/product/11.2.0Qv2/lib -lclntsh -o build/lib.linux-x86_64-2.7-11g/cx_Oracle.so Thank you for sharing your work for this module, Anthony! Thanks again, Shai and Anthony, for your responses to my previous email. Best wishes, Erik Johnson |