error importing smtplib

[Terry Reedy]

On 11/16/2012 2:37 PM, Eric Frederich wrote:
> So I inspected the process through /proc/<pid>/maps
> That seemed to show what libraries had been loaded (though there is
> probably an easier way to do this).

> In any case, I found that if I import smtplib before logging in I see
> these get loaded...
>
>      /opt/foo/python27/lib/python2.7/lib-dynload/_ssl.so
>      /lib64/libssl.so.0.9.8e
>
> Then after logging in, I see this other .so get loaded...
>
>      /opt/bar/lib64/libssl.so.0.9.7

That version appears to be about a decade old. Why is bar using it?

> So that is what happens when when things are well and I don't get any
> error messages.
> However, when I do the log in first I see the /opt/bar .so file loaded first
>
>      /opt/bar/lib64/libssl.so.0.9.7
>
> Then after importing smtplib I see the other two show up...
>
>      /opt/foo/python27/lib/python2.7/lib-dynload/_ssl.so
>      /lib64/libssl.so.0.9.8e

What I know is that hashlib.py imports _hashlib (compilied .c) and that 
the latter wraps libssl, or calls _ssl.so which wraps libssl. In *nix 
this is expected to already be on the system, so in not distributed with 
python. Furthermore, hashlib requires a version recent enough to have 
the latest (best) hash functions. I suspect decade-old 9.9.7 does not 
qualify.

What I don't know is how .so loading and linking works. It seems that 
two version get loaded but linking gets messed up. This reminds me of 
'dll hell' on Windows ;-). I don't know either if modifying the loading 
of ...9.7 in for or bar code could do anything.

> So.... I'm guessing the problem is that after I log in, the process has
> a conflicting libssl.so file loaded.
> Then when I try to import smtplib it tries getting things from there and
> that is where the errors are coming from.
>
> The question now is how do I fix this?

[easy] Do the import before the function call, which is the proper order 
and the one that works.

Remove ...9.7 from bar/lib64/ and have bar use the up-to-date system 
version, like python does. An alternative is to replace ...9.7 with a 
duplicate ...9.8e (and probably better, only load it if there is no 
system version).

>         What else should I be checking?

Thinking more, you can look at sys.modules, but this does not have any 
info about non-module libraries wrapped by modules, even if the latter 
are C-coded.

-- 
Terry Jan Reedy