Might be good to walk through a fix in the open. I am going to explain
things you may already know for the sake of others that might not.
The ar (archive n1) command allows you to see the members:
% ar -t /opt/freeware/lib/libssl.a
libssl.so.1.0.1
libssl.so.0.9.7
libssl.so.0.9.8
libssl.so.1.0.0
n1 -
http://linux.about.com/library/cmd/blcmdl1_ar.htm
The error of "Dependent module /opt/freeware/lib/libssl.a(libssl.so.1)
could not be loaded." now makes sense because libssl.so.1 isn't in the
archive located at /opt/freeware/lib/libssl.a. Everything in
/opt/freeware/lib is from perzl.org, so now let's look at the libssl.a IBM
delivers.
% ar -t /QOpenSys/usr/lib/libssl.a
libssl.so.0
libssl.so.0.9
libssl.so.0.9.8
libssl.so.1
libssl.so.1.0
libssl.so.1.0.0
Ok, the IBM version has the correct member in it. So now we need to
determine why it is not resolving to it.
[Aaron was sitting in bar sipping Blue Moon and Kevin Adler walks up demand
answers for how I discovered his tail(n2)]
n2 -
http://bit.ly/kadler-the-tails
Kevin says to run the dump command on the python3 binary (see below). We
then reviewed the "Import File Strings" section which is used to describe
search paths for resolving other libs and shared objects. You can find
more info in the following tutorial:
http://bit.ly/aix-linking (search for
"Import File Strings")
% dump -H /QOpenSys/QIBM/ProdData/OPS/Python3.4/bin/python3
/QOpenSys/QIBM/ProdData/OPS/Python3.4/bin/python3:
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x0000061a 0x00000039 0x0000019f
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000004 0x0000953c 0x0000819d 0x000096db
***Import File Strings***
INDEX PATH BASE MEMBER
0 /QOpenSys/opt/freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.
0/4.8.4/pthread:/QOpenSys/opt/freeware/bin/../lib/gcc/
powerpc-ibm-aix6.1.0.0/4.8.4/../../../pthread:/QOpenSys/opt/
freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4:/
QOpenSys/opt/freeware/bin/../lib/gcc:/QOpenSys/opt/freeware/bin/../lib/gcc/
powerpc-ibm-aix6.1.0.0/4.8.4/../../..:/usr/lib:/lib
1 libc.a shr.o
2 libpthreads.a shr_xpg5.o
3 libpython3.4m.so
Then Kevin had me do the same for _ssl.so which has reference to libssl.a
and has a similar search path that resolves to perzl first.
% dump -H
/QOpenSys/QIBM/ProdData/OPS/Python3.4/lib/python3.4/lib-dynload/_ssl.so
/QOpenSys/QIBM/ProdData/OPS/Python3.4/lib/python3.4/lib-dynload/_ssl.so:
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x000000e5 0x00000380 0x000001d4
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000005 0x00003f98 0x0000110b 0x0000416c
***Import File Strings***
INDEX PATH BASE MEMBER
0
.:/QOpenSys/QIBM/ProdData/OPS/Python3.4/lib:/QOpenSys/opt/freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4/pthread:/QOpenSys/opt/freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4/../../../pthread:/QOpenSys/opt/freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4:/QOpenSys/opt/freeware/bin/../lib/gcc:/QOpenSys/opt/freeware/bin/../lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.4/../../..:/usr/lib:/lib
1 libssl.a libssl.so.1
2 libcrypto.a libcrypto.so.1
3 libc.a shr.o
4 .
Perzl installs stuff in /opt/freeware so why would /QOpenSys/opt/freeware
in the above search paths cause an issue? Running the following command
shows /opt points at /QOpenSys/opt (symbolic link, like a Windows desktop
shortcut). By this we now know why it's resolving to perzl's libssl.a
before IBM's libssl.a
% ls -al /
lrwxrwxrwx 1 aaron 0 26 Dec 17 2015 opt ->
/QOpenSys/opt
So, what do we do now? Here are some options:
1) We could specify the LIBPATH environment variable (temporarily or
permanently) when we use Python. Temporary example: $ LIBPATH=/usr/lib pip
install mypkg Permanent for shell session example: $ export
LIBPATH=/usr/lib then $ pip install mypkg
2) We could modify libssl.a to have all the necessary, and appropriately
named, members. You can see how this is done with libiconv.a in the
ibmichroot project:
http://bit.ly/libiconv-fix Note this is done every
time the ibmichroot project installs libiconv. Maybe we should do the same
for libssl.a? Especially since libssl.a is a fairly constant perpetrator.
Kevin, thoughts on this?
3) Remove /opt/freeware/lib/libssl.a. This is risky because you could now
have the same errors with perzl tools that you had with IBM's python.
4) IBM could use the -L and -bnoipath options when they compile so they are
shielded from users introducing issues like this.
Review of options. Opt 1 is a quick solution that might work, though there
could still be issues if a perzl and IBM tool are used in the same scenario
and they both want their version of libssl.a Opt 2 is probably the best
short term option (and maybe long term). In our conversation Kevin
mentioned the 1,1.0,1.0.0 versions should be semantic (semver.org) and
therefore adding libssl.so.1 and libssl.so.1.0 to
/opt/freeware/lib/libssl.a ~should be~ fine. Opt 3 I don't like because it
will most likely cause similar heart ache to Opt 1. Opt 4 is a nice long
term solution that is necessary when open source is being sourced from
different entities.
Kevin, let me know if I've explained something incorrectly.
JohnY, let me know if you'd like to try fixing with Opt 2 or if you'd like
me to fix it for you. I won't be able to fix it until later tonight
because the common.org/forum is today/tomorrow.
Aaron Bartell
litmis.com - Services for open source on IBM i
On Tue, Aug 23, 2016 at 10:18 AM, Kevin Adler <kadler@xxxxxxxxxx> wrote:
"OpenSource" <opensource-bounces@xxxxxxxxxxxx> wrote on 08/22/2016
11:03:28 PM:
From: John Yeung <gallium.arsenide@xxxxxxxxx>
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Date: 08/22/2016 11:03 PM
Subject: [IBMiOSS] Python SSL support broken on Litmis Spaces?
Sent by: "OpenSource" <opensource-bounces@xxxxxxxxxxxx>
I am having trouble installing things using pip from my Litmis Space
for Python.
A bit of quick Googling indicates that this is most likely due to
Python not being able to find SSL support. And indeed, I get this in
an interactive Python session:
Python 3.4.4 (default, Mar 23 2016, 11:07:11)
[GCC 4.8.4] on aix6
Type "help", "copyright", "credits" or "license" for more information.
import ssl
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/QOpenSys/QIBM/ProdData/OPS/Python3.4/lib/python3.4/ssl.py",
line 97, in <module>
import _ssl # if we can't import it, let the error
propagate
ImportError: Could not load module
/QOpenSys/QIBM/ProdData/OPS/Python3.4/lib/python3.4/lib-dynload/_ssl.so.
Dependent module /opt/freeware/lib/libssl.a(libssl.so.1) could
not be loaded.
Looks like it's got the wrong libssl.a. Python is built against SC1
libssl.a, but that is complaining about the Perzl libssl.a, which is not
compatible.
John Y.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
midrange.com
