including libttsh11 fixed the problem. Thank you!<br><br>Now I can get on with fixing everything that Python 3 broke... err changed. :)<br><br clear="all">--<br><br>Cliff<br>
<br><br><div class="gmail_quote">On Sat, Aug 28, 2010 at 11:20 AM, Alexander Gattin <span dir="ltr"><<a href="mailto:xrgtn@yandex.ru">xrgtn@yandex.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello,<br>
<br>
On Sat, Aug 28, 2010 at 09:27:05AM -0400, Cliff<br>
Martin wrote:<br>
> Yes, our entire toolchain is 64 bit - a mix of<br>
> stuff I have downloaded and built and some<br>
> packages from HP (in the form of depot files)<br>
> GCC was downloaded from HP, for example.<br>
<br>
I see. I bootstrapped from bundled cc, hence all<br>
the problems.<br>
<br>
> Python -d did not generate any additional<br>
> information, and so was not helpful (should this<br>
> work?).<br>
<br>
Oops I was wrong about the python -d --<br>
correct option is -v of course...<br>
<br>
> Python -v did, however, and it came up with a<br>
> number of unresolved symbols all seeming to be<br>
> from libnnz11.so. I tried linking against all of<br>
> the *.so files in ORACLE_HOME/lib, but I don't<br>
> remember trying libttsh11 specifically. I will<br>
> try it again on Monday.<br>
<br>
You're using Oracle 11 vs our v10 (we also have<br>
v8, v9 and v11 in production, but not on this<br>
HP-UX server), but I think the problem with the<br>
libnnz is the same: Oracle doesn't put correct<br>
shared library dependencies into the libnnzXX.so<br>
dynamic section header (it should list<br>
libttshXX.so as NEEDED but apperently doesn't).<br>
<br>
Probably their distribution for Solaris is better,<br>
I didn't check (I'll ask our DBAs on Monday).<br>
<font color="#888888"><br>
--<br>
With best regards,<br>
xrgtn<br>
</font></blockquote></div><br>