Trouble importing cx_Oracle on HPUX
I have just gotten done building Python 3.1.2 on HPUX 11.31 Itanium (IA64) using gcc 4.4.3, and have tried building cx_Oracle to go with it. The build succeeds, but test and importing does not. I have tried building Python with threads and without. The only exotic thing I do with the configure for python is to supply -mlp64, which makes it a 64 bit build. Python 3 appears to work just fine, and cx_Oracle has worked on this same architecture in the past with Python 2.6.5. Help! I would really like to use Python 3, but Oracle support is a requirement. Everything I've read indicates it should work, but there is not a lot of people doing this or posting notes about their install problems or successes on HP-UX. Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble importing cx_Oracle on HPUX
Hi, thank you for getting back to me. Yes, our entire toolchain is 64 bit - a mix of stuff I have downloaded and built and some packages from HP (in the form of depot files) GCC was downloaded from HP, for example. I had to manually add -mlp64 to the CC and CXX lines in the Python Makefile to get it to build 64 bit Python 3. I also had to define PATH_MAX in about 5 files, because it was not resolving it, and it was just easier to add it than to spend more time trying to make it work. I hate HP-UX, BTW. Python -d did not generate any additional information, and so was not helpful (should this work?). Python -v did, however, and it came up with a number of unresolved symbols all seeming to be from libnnz11.so. I tried linking against all of the *.so files in ORACLE_HOME/lib, but I don't remember trying libttsh11 specifically. I will try it again on Monday. -- Cliff On Sat, Aug 28, 2010 at 9:11 AM, Alexander Gattin wrote: > Hello, > > On Thu, Aug 26, 2010 at 08:08:42PM -0700, Cliff > Martin wrote: > > I have just gotten done building Python 3.1.2 on > > HPUX 11.31 Itanium (IA64) using gcc 4.4.3, and > > have tried building cx_Oracle to go with it. The > > build succeeds, but test and importing does not. > > I have tried building Python with threads and > > without. The only exotic thing I do with the > > configure for python is to supply -mlp64, which > > BTW, did you build all GNU toolchain in 64 bit > mode? I made some tries to get 64bit python etc > but stubmled over compilation errors and didn't > get enough free time to finish the effort. > > > makes it a 64 bit build. Python 3 appears to > > work just fine, and cx_Oracle has worked on this > > same architecture in the past with Python 2.6.5. > > did you try to start python -d and > >>> import cx_Oracle? > > It may reveal that some symbols in libnnz10 aren't > resolvable. If this is the case, try linking with > bith libttsh10 and libnnz10: > > .../cx_Oracle-x.y.z $ LDFLAGS="-lttsh10" python setup.py install > > Alternatively, try linking against "static" > version of libclntsh10 -- libclntst10. > > -- > With best regards, > xrgtn > -- http://mail.python.org/mailman/listinfo/python-list
Re: Trouble importing cx_Oracle on HPUX
including libttsh11 fixed the problem. Thank you! Now I can get on with fixing everything that Python 3 broke... err changed. :) -- Cliff On Sat, Aug 28, 2010 at 11:20 AM, Alexander Gattin wrote: > Hello, > > On Sat, Aug 28, 2010 at 09:27:05AM -0400, Cliff > Martin wrote: > > Yes, our entire toolchain is 64 bit - a mix of > > stuff I have downloaded and built and some > > packages from HP (in the form of depot files) > > GCC was downloaded from HP, for example. > > I see. I bootstrapped from bundled cc, hence all > the problems. > > > Python -d did not generate any additional > > information, and so was not helpful (should this > > work?). > > Oops I was wrong about the python -d -- > correct option is -v of course... > > > Python -v did, however, and it came up with a > > number of unresolved symbols all seeming to be > > from libnnz11.so. I tried linking against all of > > the *.so files in ORACLE_HOME/lib, but I don't > > remember trying libttsh11 specifically. I will > > try it again on Monday. > > You're using Oracle 11 vs our v10 (we also have > v8, v9 and v11 in production, but not on this > HP-UX server), but I think the problem with the > libnnz is the same: Oracle doesn't put correct > shared library dependencies into the libnnzXX.so > dynamic section header (it should list > libttshXX.so as NEEDED but apperently doesn't). > > Probably their distribution for Solaris is better, > I didn't check (I'll ask our DBAs on Monday). > > -- > With best regards, > xrgtn > -- http://mail.python.org/mailman/listinfo/python-list
