I had various odd problems building python 2.2.1 under the 
FreeBSD ports, but have finally resolved it. 
 
It turns out that my standard system setup includes two 
environment variables which are used in shell scripts to 
generate inverse video.  They are SO and SE, for 
standout and standend, as per the classic termcap/termlib 
variables. 
 
Unfortunately, the ./configure script uses SO as the 
extension for shared libraries.  If it is previously defined, 
the value is retained rather than developed by test.  Thus 
my python builds were looking for shared libraries with 
the name foo.<ESC>[7m rather than foo.so. 
 
I found two fixes which worked.  One was to undefine SO. 
The other was to rummage thru configure, configure.in and 
Makefile.pre.in at the top dir and change SO to SHLIBEXT. 
After either, the configure/builds ran fine. 
 
I notice in those files that SO is pretty much the *only* 
two-character variable name used that is not already 
strongly associated with a 'standard' name for builds 
via make (CC, LD, etc).  I have not encounted any other 
use of SO except python's and mine. 
 
While I'm not presumptuous enough to suggest that pythons 
build should change to avoid my problems, I *will* note 
that long, meaningful variable names are alwas better than 
short, obscure, misleading ones.  While SO does reflect 
the UNIX shared library, it's a bit misleading for DLLs, etc. 

Logged In: YES 
user_id=21627

When changing this, I'm concerned that third-party code may
break which relies on the extension being SO. I'd like to
hear other opinions on whether this should or should not be
changed.

Logged In: YES 
user_id=161331

Sorry, you're confusing the variable name and the shared file 
extension name.  For UNIX systems, the extension has to be .so; 
it has to be .dll for Windows, etc.  The internal variable the 
build process uses to hold the extension is a separate item. 

Logged In: YES 
user_id=21627

I'm not confusing the two. I'm concerned that extensions
module build procedures read through the generated makefile,
try to extract SO from it, and make use of this. It appears
that your requested change would break such build procedures.

I'm not worried about the actual extension; I know it has to
be .so or .sl on Unix.

Logged In: YES 
user_id=21627

I think this should be solved by unsetting SO before
configuration. I have added a warning in

configure.in 1.416
configure 1.405

if SO is set, to allow the user to interrupt configure.