Hi,

I just wanted to try out Mailman on a Sun Solaris
machine and compiled therefore Python 2.2.

It did compile ok, but there seems to be a problem with
the socket library:

bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py
Traceback (most recent call last):
  File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket


Could you help me with this problem.

Thanks a lot
Philipp Kolmann

Logged In: YES 
user_id=6656

The problem is probably ssl support.  Try editing
Modules/Setup and uncommenting the line:

#_socket socketmodule.c

If you *need* ssl support, then you'll have to dig deeper...

Logged In: YES 
user_id=6380

MWH: I don't see the connection with SSL. More likely
somehow the socket module didn't get built. Quite possibly
his whole installation is hosed. Reducing the priority since
local configuration errors are usually not something that
Python can do anything about.

Logged In: YES 
user_id=6656

But the usual reason for the _socket module not to build on
solaris is ssl issues.  Without more info it's hard to say
anything more (hint, hint, Philipp).

Logged In: YES 
user_id=12800

This is an ld.so problem.  I can reproduce this on the SF
compile farm's Solaris8/Sparc box.  Python 2.2's brain
damaged dynlib build procedure removes any .so it can't
import, which makes it very difficult to tell what the
problem is, if it's not evident in the compilation output.  

In this particular case, rebuilding _socket.so by hand, and
then importing it clearly shows that the dynamic linker
can't find libssl.so.xxx and libcrypto.so.xxx.  On this
Solaris box, these libraries reside in /usr/local/ssl/lib
but that's not on the default ld.so search path and the
build script doesn't use the -R option to compile in the
location of those libraries.

The fix is to add "runtime_library_dirs = ssl_libs," to the
Extension constructor for socketmodule.c in the top level
setup.py.  I've tested this with Python 2.2 maint, but I'll
bet it'll hit Python 2.3 too.

Attached is a patch that ought to fix the problem for
Solaris.  It appears to do no harm on Linux.  Under the same
rationale we came up with for the bsddb module, I think this
should be added, otherwise the socket module will just plain
be busted for (some? all? most?) Solaris systems.

Logged In: YES 
user_id=12800

BTW, this is a duplicate of 551353, which is currently
closed (and I'm keeping it closed since we don't need two
open bugs on the same issue).

However, in 551353 Martin outlines some approaches that a
user can take so that the .so files are properly found at
runtime.  I must disagree that Python can't do better.  We
hashed out a similar issue with the bsddb library which
installs in /usr/local/BerkeleyDB.X.Y by default, also not
on the default ld search path.  In that case we agreed to
add the setup.py magic to compile in the runtime path to the
library, and I think we should do the same with the ssl library.

setup.py already finds the dynamic libraries so it can just
as easily add the -R flag.  Too many people get bit by this
problem and there are basically no diagnostics to help
someone figure out what needs to be done to fix the problem.
 In 551353, Martin says that sometimes adding -R isn't
right, but I think for most people it will be right.  For
those that adding -R does the wrong thing, they can hack the
code, and I believe that adding -R will make life better for
the majority of users.

I assigned this to Guido for pronouncement.

Logged In: YES 
user_id=6380

OK, I think I now understand -- the question is, should we
add -R to find the SSL library or not? I think yes, at least
if we know the platform supports -R.

BTW setup.py badly needs an option to prevent it from
throwing away failing .so files!

Assigning to Martin so he can explain the problem with -R
again if he disagrees with my pronouncement; I looked at
551553 but didn't understand the problem.

Logged In: YES 
user_id=12800

Note that setup.py doesn't need to explicitly add the -R
option.  It just needs to add runtime_library_dirs=ssl_libs
and distutils will do the right thing crossplatform
(verified on Solaris and Linux).

Logged In: YES 
user_id=21627

I have now been convinced that this is a good solution.
While it may be overkill in some cases (e.g. if libcrypto
isn't shared), I have to take my earlier view that setup.py
only needs to deal with the common case, and special cases
can be dealt with in Modules/Setup.

Logged In: YES 
user_id=12800

Cool, thanks Martin.  I plan to commit the one line change
to setup.py for both Python 2.3 and 2.2.2.  I'll try to add
an option to setup.py to not throw away un-importable .so's
as Guido suggests (I'd also like it to print the ImportError
to stderr if possible).

Logged In: YES 
user_id=21627

As for the setup.py option - I think what users really needs
is to find out why importing the module fails, i.e. the
complete ImportError diagnostics; the 2.3 setup.py is
supposed to report all this.

It probably would not have helped in this case, where the
user did not notice the error message at build time.
However, adding an option to setup.py would not have helped,
either - the user would not have used it.

Logged In: YES 
user_id=12800

Ok, if Python 2.3's setup.py provides the ImportError
diagnostics, then  agree that's most of what you need. 
You'll see the ld.so error so that should be a strong
indication that you're linking against a library in a
non-standard location.  I also seem to recall that Python
2.3 doesn't remove the .so, but instead moves it aside so
that's also enough because then you can use ldd and other
tools to figure out what it should have been linking to.

I'm not sure it's worth porting all this back to Python
2.2.2, so I'm closing this issue.

Logged In: YES 
user_id=59803

Just ran into this one with Python 2.2.2 on Solaris 2.7. 

The solution was to edit Modules/Setup and uncomment the 
lines after the "# Socket module compiled with SSL support" 
comment. 

I'm adding this note so that anyone else finding this bug 
doesn't have to go through the same blundering steps I did to 
figure out the solution. 

Python 2.3a1 worked flawlessly. Whatever you changed, 
worked.