Trouble importing cx_Oracle on HPUX

[Cliff Martin]

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

 

[Alexander Gattin]

Hello,

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

 

[Alexander Gattin]

Hello,

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