Hi,
  although the issues libraries to be created with -fpic are known I
still do believe ./config could do something here:

building 'crypt' extension
gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypt -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
Text relocation remains                         referenced
    against symbol                  offset      in file
_des_setkey                         0x4         /usr/lib/libcrypt.a(crypt.o)
_des_encrypt                        0x10        /usr/lib/libcrypt.a(crypt.o)
_des_crypt                          0x1c        /usr/lib/libcrypt.a(crypt.o)
<unknown>                           0x4        
/usr/lib/libcrypt.a(des_crypt.o)
<unknown>                           0x8        
/usr/lib/libcrypt.a(des_crypt.o)
...
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
# gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o
-L/usr/local/lib -lcrypto -o build/lib.solaris-2.6-sun4u-2.5/crypt.so
#

Why didn't it link with /usr/lib/libcrypt.so? That has always worked on
Solaris, including Solaris 2.6.

In addition, even if it did decide to use libcrypt.a for some strange
reason, it should still link successfully, since libcrypt.a should
define _des_encrypt. Please do "ar tv /usr/lib/libcrypt.a", and report
the object files contained in the library.

# ar tv /usr/lib/libcrypt.a
rw-rw-r-- 0/1   1296 Jul 16 05:57 1997 crypt.o
rw-rw-r-- 0/1   4996 Jul 16 05:57 1997 cryptio.o
rw-rw-r-- 0/1   1508 Jul 16 05:57 1997 des_encrypt.o
rw-rw-r-- 0/1   5356 Jul 16 05:58 1997 des_crypt.o
# ls -la /usr/lib/libcrypt.so
ls: cannot access /usr/lib/libcrypt.so: No such file or directory
#

Something must be broken with your system installation. des_crypt.o
should define the function _des_crypt (ar x /usr/lib/libcrypt.a;nm -g
des_crypt.o). What linker are you using?

It seems that the shared version of libcrypt was only added in Solaris
7, but the static version should work regardless.

Regards,
Martin

# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
#

The installation is actually very fresh, as I re-installed the
machine some year ago but it was turned off since few days. With
whatever last aggregate patches were available on dying Solaris
web pages.

# gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 3.4.2
#

Ok. I have no further ideas on what the problem might be, but I'm
confident that linking with a different library is not the right thing
to do. Linking with -lcrypt did always work on Solaris 2.6, so I'm not
going to change that.

Could it be the name clashing problem between -lcrypt and -lcrypto?

bash-3.00# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
bash-3.00# ar x /usr/local/lib/libcrypto.a;nm -g des_crypt.o
         U ___errno
0000033c T _des_crypt
00000274 T _des_encrypt
         U _des_encrypt1
000001b0 T _des_setkey
         U _mutex_lock
         U _mutex_unlock
         U _thr_getspecific
         U _thr_keycreate
         U _thr_setspecific
0000033c W des_crypt
00000274 W des_encrypt
000001b0 W des_setkey
         U free
         U malloc
bash-3.00#

There used to be name clashes between -lcrypt from KTH-KRB/HEIMDAL
with those from openssl -lcrypto in the past. I think that was
"fixed" around/in openssl-2.7 and heimdal-1.0. The clashes caused
openssh dying when compiled with kerberos4 support because the
functions of same names expected in some way different data.
I am sure you would Goggle it out.

No. We are not linking with libcrypto at all, so there can't be clashes.

You say "did always work"?

http://mail.python.org/pipermail/python-list/2002-December/177479.html

Maybe the reason why in ruby they forced to -shared flag
because it was possible to link only with the shared library?
I do not know from which package to get the shared version. :(
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/33517

Ah, ok. I completely missed the point of the error message (i.e.
"relocations remain"), and misinterpreted it as missing symbols.

So I still recommend doing what I recommended back then: Uncomment the
line in Modules/Setup to build the crypt module on Solaris 2.6. That
should still work as it always did.

Confirming the enabling line 216 like below helped. Thanks. Maybe change
"Resolution"?

    204 # Socket module helper for SSL support; you must comment out the
other
    205 # socket line above, and possibly edit the SSL variable:
    206 #SSL=/usr/local/ssl
    207 #_ssl _ssl.c \
    208 #       -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
    209 #       -L$(SSL)/lib -lssl -lcrypto
    210 
    211 # The crypt module is now disabled by default because it breaks
builds
    212 # on many systems (where -lcrypt is needed), e.g. Linux (I believe).
    213 #
    214 # First, look at Setup.config; configure may have set this for you.
    215 
    216 crypt cryptmodule.c # -lcrypt   # crypt(3); needs -lcrypt on
some systems