Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Problem building 64-bit python 2.6.2 on Solaris 10 (http://www.velocityreviews.com/forums/t685922-problem-building-64-bit-python-2-6-2-on-solaris-10-a.html)

John Center 05-28-2009 08:47 PM

Problem building 64-bit python 2.6.2 on Solaris 10
 
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 05-28-2009 10:03 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
> 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 05-29-2009 12:35 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
On May 28, 6:03*pm, "Martin v. L÷wis" <mar...@v.loewis.de> wrote:
> > 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


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 05-29-2009 11:13 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
>>> 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

John Center 06-01-2009 01:05 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
On May 29, 7:13*pm, "Martin v. L÷wis" <mar...@v.loewis.de> wrote:
>
> 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 06-01-2009 04:13 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
> 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 06-02-2009 12:25 PM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
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 06-03-2009 06:49 AM

Re: Problem building 64-bit python 2.6.2 on Solaris 10
 
> 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


All times are GMT. The time now is 03:03 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.