_socket on solaris

[yose]

"Donn Cave" <donn at u.washington.edu> wrote in message news:<aarpc9$1jb4$1 at nntp6.u.washington.edu>...
> Quoth Phil Eschallier <phil at buxtech.com>:
> ...
> | 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.
> 
> You might submit a bug report for this.  It sounds to me like more
> than strictly a Solaris problem - I would expect to see it on Digital
> UNIX, for example, and surely others.
> 
> In my experience with Digital UNIX, if I make a xyzmodule.so that
> depends on libxy.so, I have to build python so that it can find
> libxy.so (-rpath or whatever) before it can import xyz.  Which is
> kind of unfortunate, it would be nice to be able to build a module
> and just run it, without needing to rebuild python.
> 
> 	Donn Cave, donn at u.washington.edu


How do I find the fix for this, if there is one?