0005210: Importig SSL module on Solaris 10 results in ImportError

(0010932)
dam (administrator)
2014-10-06 13:22

I cannot reproduce this. With my test host connected to "testing" I get

dam@testing10s [testing10s]:/home/dam > python2.7
Python 2.7.6 (default, May 4 2014, 00:57:49)
[GCC 4.9.0] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>>

(0010933)
maciej (reporter)
2014-10-09 16:11

FYI this bug blocks the promotion of latest Python packages from unstable to testing.
(this might be what you want)

(0010934)
wungad (reporter)
2014-10-09 19:16

This has so be some kind of compile/linking error:

$ which pydoc
/opt/csw/bin/pydoc

$ pydoc ssl
problem in ssl - <type 'exceptions.ImportError'>: ld.so.1: python2.7: fatal: relocation error: file /opt/csw/lib/python2.7/lib-dynload/_ssl.so: symbol GENERAL_NAME_free: referenced symbol not found

(0010935)
wungad (reporter)
2014-10-09 19:54

Is is possible that updated libc is needed? Can you show me your out put for:
ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so

(0010976)
dam (administrator)
2014-11-19 22:25

I have

dam@unstable10s [unstable10s]:/home/dam > ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so
        libssl.so.1.0.0 => /opt/csw/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 => /opt/csw/lib/libcrypto.so.1.0.0
        libpython2.7.so.1.0 => /opt/csw/lib/libpython2.7.so.1.0
        libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
        libc.so.1 => /lib/libc.so.1
        libcrypto.so.1.0.0 => /opt/csw/lib/sparcv8plus+vis/libcrypto.so.1.0.0
        libsocket.so.1 => /lib/libsocket.so.1
        libnsl.so.1 => /lib/libnsl.so.1
        librt.so.1 => /lib/librt.so.1
        libdl.so.1 => /lib/libdl.so.1
        libm.so.2 => /lib/libm.so.2
        libmp.so.2 => /lib/libmp.so.2
        libmd.so.1 => /lib/libmd.so.1
        libscf.so.1 => /lib/libscf.so.1
        libaio.so.1 => /lib/libaio.so.1
        libdoor.so.1 => /lib/libdoor.so.1
        libuutil.so.1 => /lib/libuutil.so.1
        libgen.so.1 => /lib/libgen.so.1
        /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1
        /platform/SUNW,SPARC-Enterprise-T5220/lib/libmd_psr.so.1

Please make sure to test on Solaris 10u8 as this is the earliest release we support.

(0010977)
wungad (reporter)
2014-11-20 07:00
edited on: 2014-11-20 07:01

$ ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so | grep 'not found'
        libc.so.1 (SUNW_1.22.5) => (version not found)
        libc.so.1 (SUNW_1.22.5) => (version not found)

Ok, it seems it's the same issue as many of other tools. SUNW_1.22.5 is needed, but we only have SUNW_1.22.2:

$ pvs -s /lib/libc.so | grep SUNW_1.22 SUNW_1.22.3:
        SUNW_1.22.2:
        SUNW_1.22.1:
        SUNW_1.22:

We're running Solaris 10u6:
$ cat /etc/release
                      Solaris 10 10/08 s10s_u6wos_07b SPARC
           Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 27 October 2008

Since libc is not a subject to big changes I presume your binaries could be rebuilt against an older version of libc. If that is not the case just close the issue and we're done.

(0010981)
dam (administrator)
2014-11-21 08:50

The problem is that it is hard to rebuild transitive toolchains as all dependencies must then link to the lower ABI. Additionally, there are interdependencies between different libraries like libc and libnsl when a function from libnsl from the recent version uses a function only available in a new libc - then you are basically stuck with downreving the Solaris on the buildfarm (which we can't do as some fixes we rely on in ZFS and the linker are only available in later releases). So in short in short I suggest you just update to u11 and everything works as expected.

(0010982)
wungad (reporter)
2014-11-21 09:01

Yeah, I thought so. The update is out of the question for these machines. Ok, as long as we know what's going on. Please close this issue.

(0010992)
dam (administrator)
2014-12-10 14:30

Closing on request

Notes
(0010932) dam (administrator) 2014-10-06 13:22	I cannot reproduce this. With my test host connected to "testing" I get dam@testing10s [testing10s]:/home/dam > python2.7 Python 2.7.6 (default, May 4 2014, 00:57:49) [GCC 4.9.0] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>>

(0010933) maciej (reporter) 2014-10-09 16:11	FYI this bug blocks the promotion of latest Python packages from unstable to testing. (this might be what you want)

(0010934) wungad (reporter) 2014-10-09 19:16	This has so be some kind of compile/linking error: $ which pydoc /opt/csw/bin/pydoc $ pydoc ssl problem in ssl - <type 'exceptions.ImportError'>: ld.so.1: python2.7: fatal: relocation error: file /opt/csw/lib/python2.7/lib-dynload/_ssl.so: symbol GENERAL_NAME_free: referenced symbol not found

(0010935) wungad (reporter) 2014-10-09 19:54	Is is possible that updated libc is needed? Can you show me your out put for: ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so

(0010976) dam (administrator) 2014-11-19 22:25	I have dam@unstable10s [unstable10s]:/home/dam > ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so libssl.so.1.0.0 => /opt/csw/lib/libssl.so.1.0.0 libcrypto.so.1.0.0 => /opt/csw/lib/libcrypto.so.1.0.0 libpython2.7.so.1.0 => /opt/csw/lib/libpython2.7.so.1.0 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libcrypto.so.1.0.0 => /opt/csw/lib/sparcv8plus+vis/libcrypto.so.1.0.0 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 librt.so.1 => /lib/librt.so.1 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libaio.so.1 => /lib/libaio.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 /platform/SUNW,SPARC-Enterprise-T5220/lib/libmd_psr.so.1 Please make sure to test on Solaris 10u8 as this is the earliest release we support.

(0010977) wungad (reporter) 2014-11-20 07:00 edited on: 2014-11-20 07:01	$ ldd /opt/csw/lib/python2.7/lib-dynload/_ssl.so \| grep 'not found' libc.so.1 (SUNW_1.22.5) => (version not found) libc.so.1 (SUNW_1.22.5) => (version not found) Ok, it seems it's the same issue as many of other tools. SUNW_1.22.5 is needed, but we only have SUNW_1.22.2: $ pvs -s /lib/libc.so \| grep SUNW_1.22 SUNW_1.22.3: SUNW_1.22.2: SUNW_1.22.1: SUNW_1.22: We're running Solaris 10u6: $ cat /etc/release Solaris 10 10/08 s10s_u6wos_07b SPARC Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 Since libc is not a subject to big changes I presume your binaries could be rebuilt against an older version of libc. If that is not the case just close the issue and we're done.

(0010981) dam (administrator) 2014-11-21 08:50	The problem is that it is hard to rebuild transitive toolchains as all dependencies must then link to the lower ABI. Additionally, there are interdependencies between different libraries like libc and libnsl when a function from libnsl from the recent version uses a function only available in a new libc - then you are basically stuck with downreving the Solaris on the buildfarm (which we can't do as some fixes we rely on in ZFS and the linker are only available in later releases). So in short in short I suggest you just update to u11 and everything works as expected.

(0010982) wungad (reporter) 2014-11-21 09:01	Yeah, I thought so. The update is out of the question for these machines. Ok, as long as we know what's going on. Please close this issue.

(0010992) dam (administrator) 2014-12-10 14:30	Closing on request

Relationships

OpenCSW Bug Tracker