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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem building 64-bit python 2.6.2 on Solaris 10
On May 28, 6:03 pm, "Martin v. Löwis" 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem building 64-bit python 2.6.2 on Solaris 10
On May 29, 7:13 pm, "Martin v. Löwis" 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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
