Problem building 64-bit python 2.6.2 on Solaris 10
"Martin v. Löwis"
martin at v.loewis.de
Sat May 30 01:13:51 CEST 2009
>>> I think the problem is it should be built with v9.S for 64-bit, not
>>> v8.S. Is that correct? If so, how do I get it to use the right one?
>> The Solaris dynamic loader can't find it. Set LD_LIBRARY_PATH or
>> LD_RUN_PATH appropriately, or use crle(8).
> I'm not sure I understand. It appears that cc is compiling the wrong
> module, v8.S.
Ah, too much text - I was confused by you reporting two issues in a
single email message. That has exhausted my capacity for quick message
So this is a ctypes problem. You'll have to ignore it - there is
absolutely no way that you could possibly build the ctypes module
with Sun CC (short of rewriting ctypes to support it, of course).
Use gcc if you need the ctypes module, or accept not having the ctypes
> You may be right about the first error. It's being reported by ld,
> but -L/opt/openssl/lib/sparcv9 & -R/opt/openssl/lib/sparcv9 are being
> passed to cc. It is able to find -lssl & -lcrypto, but I think python
> itself doesn't use the openssl libraries. Since I see the chain
> "ld.so.1: python: fatal: libssl.so.0.9.8: open failed: No such file or
> directory", which I think means python itself doesn't know where they
> are at. I checked python & libpython.so with ldd & neither uses
> libssl.so. It seems to me there should be another way to tell python
> where to find it to build the module. Does this make sense?
Unfortunately, no. It is definitely *not* Python who is searching for
these libraries. That you had been passing them to ld during linkage
doesn't help at all. Linking succeeds just fine; Python then tries
to load the the _ssl module, which in turn causes the *dynamic* linker
(ld.so.1) to search for the shared library; it doesn't find it and
therefore gives up loading _ssl.so.
More information about the Python-list