In summary: distutils picks up and uses the proper
values for -I and -L when compiling.  However, Solaris
(and likely other SysV UNIX variants) need -R to the
linker as well.

I posted something to USENET trying to help someone
having _socket problems under Solaris.  The follow-ups
suggested that I create this bug report.

From USENET:

Folks;

I'm in no way a Python expert ... but I've been playing
with it under
Solaris for the last week, thinking that we should make
the jump from
perl (a different thread).

I wanted to follow-up noting that the build process for
Python under
Solaris is less than perfect.  I've experienced this
same _socket
module not being found and "yes", the build is broken.

The root of the issue is that the distutils used for
compiling
determine the libs needed and add the -I / -L as
needed.  But no -R
options are added.  My problem came from the fact that
I have OpenSSL
deployed under /usr/local/ssl ... and the build process
adds the -L to
find ssl.so and crypt.so ... but the resulting
_socket.so does not
have the runtime path to the OpenSSL libs, the test
load of _socket.so
fails, and it is removed from the build.  The same
holds for TK
support and one or two others.

Under Linux this is a non-issues as ldconfig is available.

My work-around for now is to add all the -L / -R
directives I need to
the CC environment variable before running the initial
'configure'
script (because only hte CC and LDSHARED variables are
passed from
Makefile to setyp.py).

I hope this helps ... and I hope that Python becomes
more Solaris
friendly as it matures.


Cheers.

-- 
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA  18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com

Logged In: YES 
user_id=21627

When you say that you can accept the Linux build because of
ldconfig(8), then I suggest using crle(1) on Solaris - it
does exactly the same thing.

You have the following options on Solaris:
1) build static PIC libraries of SSL, and use those
2) use crle
3) set LD_RUN_PATH before configuring Python
4) edit Modules/Setup
5) set LD_LIBRARY_PATH at run time

I think these are plenty of options. The Python build is not
Solaris-unfriendly - just if you, as an administrator,
install additional shared libraries on your system, you must
take additional steps when you want to use them.

Outright adding a -R option for every -L option is not the
right solution; if the library to link is static-with-PIC,
then this would be wrong; if crle is used, this would be
also wrong. My recommendation is to abstain from shared
libraries in non-standard directories.

In short, I don't think there is much that can be done about
this. In Python 2.3, the socket and ssl modules are
separate, so you will get socket module even if building the
ssl module fails.

Logged In: YES 
user_id=31392

The options Martin outlines sound sufficient to me.

Logged In: YES 
user_id=532350

jhylton;

Thank you for your time.  While I understand and accept your
closure statement, I was hoping for a bit more universal
solution.  I believe that crle was introduced to Solaris in
2.6; many of my clients still have older versions of the OS
in production and cannot easily upgrade (both political and
technical issues involved) ... so a single style of Solaris
deployment of python would have been nice.

I have a hack designed to get around this.  A number of
USENET readers have followed up with me via E-mail asking
for support, so my original report to you is apparently
affecting more than just my world.

Of course your solution is correct in the purely technical
sense, we'll see how others in the Solaris community react
over time.

Again, thank you.  ... Phil