>>> 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 scanning. 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 module available. > 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. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
