Problem building 64-bit python 2.6.2 on Solaris 10

[John Center]

Hi,

I'm trying to build python 2.6.2 on Solaris 10 (SPARC 64), using Sun
Studio 12, but I'm having a few problems getting a clean build. The
python configure options are:

with_gcc=no
with_universal_archs=64-bit
with_cxx_main="CC -m64"

The first problem I'm having is _ssl.so not building:

cc -m64 -xcode=pic32 -DNDEBUG -g -xs -xtarget=ultraT1 -xarch=sparcvis2
-m64 -mt
-xcode=pic32 -xmemalign=8s -xpagesize=default -I. -I/opt/ws/dists/
Python-2.6.2/.
/Include -I. -IInclude -I./Include -I/opt/db/include -I/opt/tcl8/
include -I/opt/
openssl/include -I/opt/gnu/include -I/opt/local/include -I/usr/sfw/
include -I/usr/include -I/usr/local/include -I/opt/ws/dists/
Python-2.6.2/Include -I/opt/ws/dists/Python-2.6.2 -c /opt/ws/dists/
Python-2.6.2/Modules/_ssl.c -o build/temp.solaris-2.10-sun4v-2.6/opt/
ws/dists/Python-2.6.2/Modules/_ssl.o
"/opt/ws/dists/Python-2.6.2/Modules/_ssl.c", line 1119: warning:
statement not reached
cc -m64 -G build/temp.solaris-2.10-sun4v-2.6/opt/ws/dists/Python-2.6.2/
Modules/_ssl.o -L/opt/openssl/lib/sparcv9 -L/opt/db/lib/sparcv9 -L/opt/
gnu/lib/sparcv9 -L
/opt/local/lib/sparcv9 -L/usr/sfw/lib/sparcv9 -L/usr/lib/sparcv9 -L/
usr/local/lib -L. -R/opt/db/lib/sparcv9 -R/opt/gnu/lib/sparcv9 -R/opt/
local/lib/sparcv9 -R/usr/sfw/lib/sparcv9 -R/usr/lib/sparcv9 -lssl -
lcrypto -lpython2.6 -o build/lib.so
laris-2.10-sun4v-2.6/_ssl.so

*** WARNING: renaming "_ssl" since importing it failed: ld.so.1:
python: fatal: libssl.so.0.9.8: open failed: No such file or directory

I have the openssl include & 64-bit libraries in the paths shown
above, so why this doesn't work? What am I missing?


My next problem is building the ctypes module:

cc -m64 -xcode=pic32 -DNDEBUG -g -xs -xtarget=ultraT1 -xarch=sparcvis2
-m64 -mt
-xcode=pic32 -xmemalign=8s -xpagesize=default -I. -I/opt/ws/dists/
Python-2.6.2/.
/Include -Ibuild/temp.solaris-2.10-sun4v-2.6/libffi/include -Ibuild/
temp.solaris
-2.10-sun4v-2.6/libffi -I/opt/ws/dists/Python-2.6.2/Modules/_ctypes/
libffi/src -
I. -IInclude -I./Include -I/opt/db/include -I/opt/tcl8/include -I/opt/
openssl/include -I/opt/gnu/include -I/opt/local/include -I/usr/sfw/
include -I/usr/include
-I/usr/local/include -I/opt/ws/dists/Python-2.6.2/Include -I/opt/ws/
dists/Python
-2.6.2 -c /opt/ws/dists/Python-2.6.2/Modules/_ctypes/libffi/src/sparc/
v8.S -o build/temp.solaris-2.10-sun4v-2.6/opt/ws/dists/Python-2.6.2/
Modules/_ctypes/libffi
/src/sparc/v8.o

/opt/ws/tools/SUNWspro/prod/bin/fbe: "/opt/ws/tmp/dists/cpp0AAA.
19506.DfaqgM", l
ine 438: error: detect global register use not covered .register
pseudo-op
/opt/ws/tools/SUNWspro/prod/bin/fbe: "/opt/ws/tmp/dists/cpp0AAA.
19506.DfaqgM", l
ine 456: error: detect global register use not covered .register
pseudo-op
cc: assembler failed for /opt/ws/dists/Python-2.6.2/Modules/_ctypes/
libffi/src/s
parc/v8.S

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?

Any help would be greatly appreciated.

-John

 

[Martin v. Löwis]

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

Regards,
Martin

 

[John Center]

The Solaris dynamic loader can't find it. Set LD_LIBRARY_PATH or
LD_RUN_PATH appropriately, or use crle(8).

Regards,
Martin

Hi Martin,

I'm not sure I understand. It appears that cc is compiling the wrong
module, v8.S. It should be compiling v9.S. The errors are being
reported by fbe, the Sun Studio assembler, not ld. I think there must
be a place to specify which I want to use, but I don't understand the
python build environment well enough to know where to do it.

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?

Thanks for your help.

-John

 

[Martin v. Löwis]

I think the problem is it should be built with v9.S for 64-bit, not

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

 

[John Center]

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.

Sorry about that. I have a tendency to over document...

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.

I was afraid that would be the case. I have gcc4sparc, but I usually
build with Sun Studio. I believe gcc4sparc uses the Sun Studio
backend. I'll try this, but do you know if I would need to do
anything different to get the ctypes code to compile?

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.

Ok, so it looks like the only option here is to use LD_LIBRARY_PATH.

Thanks, Martin.

-John

 

[Martin v. Löwis]

Ok, so it looks like the only option here is to use LD_LIBRARY_PATH.

Not really: there is also crle, and LD_RUN_PATH.

Regards,
Martin

 

[John Center]

Hi Martin,

I was able to compile ctypes with gcc4sparc without many changes to
the CFLAGS, etc. I had another weird error, but upgrading to the
latest gcc4sparc fixed it. One thing I'm not clear about is how
extensions are built. I noticed that my CFLAGS are not being passed
to gcc when building the extensions, so some of them are failing to
find the correct includes & libraries. How does one pass these flags?

Thanks.

-John

 

[Martin v. Löwis]

I was able to compile ctypes with gcc4sparc without many changes to

the CFLAGS, etc. I had another weird error, but upgrading to the
latest gcc4sparc fixed it. One thing I'm not clear about is how
extensions are built. I noticed that my CFLAGS are not being passed
to gcc when building the extensions, so some of them are failing to
find the correct includes & libraries. How does one pass these flags?

The most reliable strategy is to edit Modules/Setup, and uncomment
the modules where you want to pass flags. These will then not be built
through setup.py (but become builtin by default).

Regards,
Martin