Problem building 64-bit python 2.6.2 on Solaris 10

Discussion in 'Python' started by John Center, May 28, 2009.

  1. John Center

    John Center Guest

    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
    John Center, May 28, 2009
    #1
    1. Advertising

  2. > 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
    Martin v. Löwis, May 28, 2009
    #2
    1. Advertising

  3. John Center

    John Center Guest

    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
    John Center, May 29, 2009
    #3
  4. >>> 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
    Martin v. Löwis, May 30, 2009
    #4
  5. John Center

    John Center Guest

    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
    John Center, Jun 1, 2009
    #5
  6. > 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
    Martin v. Löwis, Jun 1, 2009
    #6
  7. John Center

    John Center Guest

    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
    John Center, Jun 2, 2009
    #7
  8. > 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
    Martin v. Löwis, Jun 3, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    0
    Views:
    461
  2. Dave Harrison

    Solaris 9, problem building Python 2.1.1

    Dave Harrison, Jul 16, 2003, in forum: Python
    Replies:
    0
    Views:
    552
    Dave Harrison
    Jul 16, 2003
  3. Replies:
    3
    Views:
    1,743
    Timothy Bendfelt
    Jan 19, 2007
  4. Andrey Rusanov

    building 32-bit on 64-bit system

    Andrey Rusanov, Jun 7, 2010, in forum: C++
    Replies:
    10
    Views:
    2,043
    red floyd
    Jun 9, 2010
  5. Tony Arcieri
    Replies:
    8
    Views:
    221
    nobuyoshi nakada
    Sep 29, 2005
Loading...

Share This Page