Trying to execute the makefile for Python 2.3.1 and 2.3.
2c on an SCO-box results in a lot of warnings like:

*** WARNING: importing extension "struct" failed with 
exceptions.AttributeError:
 'module' object has no attribute 'load_dynamic'

This results in not being able to import the struct (and 
many others) module in the Python interpreter:

Python 2.3.2c1 (#7, Oct  1 2003, 12:08:43) [C] on 
sco_sv3
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import struct
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named struct

See the attached make.out file, which includes the 
generated makefile for my system, followed by the output 
sent to stdout.

Installing Python 2.2.3 went almost flawless.


>uname -X

System = SCO_SV
Node = ontwik2
Release = 3.2v5.0.5
KernelID = 98/07/02
Machine = i80386
BusType = ISA
Serial = 5FL004745
Users = 30-user
OEM# = 0
Origin# = 1
NumCPU = 2

Logged In: YES 
user_id=29957

Ugh. I don't have access to any SCO boxes to debug this.
Could you rebuild Python 2.2 on the same platform and attach
the output (as you did for 2.3). Obviously something's
changed in how we invoke the dynamic linker or some such.

Logged In: YES 
user_id=6656

It looks like the module 'imp' is messed up.  That's strange.

Logged In: YES 
user_id=29957

Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't
being defined. Could you also attach the files configure.log
and pyconfig.h from the 2.3 build?

Logged In: YES 
user_id=878033

Got to go home now. Hope I can help you further tomorrow.
-RE-

Logged In: YES 
user_id=6656

Can you attach the config.log for 2.2.3?  I'm now a little
curious as to how dynamic linking ever worked on this system
(which is fairly old, right?)

Logged In: YES 
user_id=878033

I uploaded both the config.log and the pyconfig.h for 2.2.3.
I'm curious what you think of it. The system is quite old, 
indeed (but we have even older among our customer base, as 
they are not very much inclined to investing in hardware!).
It is much used, though.

Regards,
Roger

Logged In: YES 
user_id=6656

Curioser and curioser.  The difference seems to be that
configure for 2.2.3 passes "-belf" to cc when checking for
dlopen but configure for 2.3 doesn't.

I actually have an idea how this happens: in 2.3, the CFLAGS
variable was split up into BASECFLAGS and OPT.  We know we
need -belf on SCO, so we stuff that into BASECFLAGS. 
However, this *doesn't* make the rest of the configure tests
use -belf -- result breakage.

(Martin, are you reading this?  Does this sound reasonable?)

Roger, can you try the attached patch?  It's a bit of a hack...

Logged In: YES 
user_id=878033

Hi Michael,

nice hack for a first time: no warnings this time, as you can 
see in the attached make.out. Thanks a lot!

Only a few compiler errors remain, but I cannot be bothered 
with them right now. So just FYI (after running make; make 
clean):

>make > make.out
"Objects/stringobject.c", line 1765: warning: statement not 
reached
"/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 
556: error: undefine
d symbol: h_errno
"/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 
184: error: undefine
d symbol: h_errno
"/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 
2374: error: undefi
ned symbol: h_errno
"/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 
2972: error: undefi
ned symbol: AF_INET6
"/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 
3016: error: undefi
ned symbol: INET_ADDRSTRLEN
"/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 
3016: error: integr
al constant expression expected
"/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 
3055: warning: stat
ement not reached
"/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 
1553: warning: arg
ument is incompatible with prototype: arg #1
"/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 
1554: warning: arg
ument is incompatible with prototype: arg #1
"/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 
1964: warning: ass
ignment type mismatch

Logged In: YES 
user_id=6656

Glad to have my suspicions confirmed!  The reason my patch
was a hack is that it patches up SCO ok, but this is at
least potentially a problem on other platforms.  Given the
lack of similar bug reports, though, perhaps it isn't.

The remaining warnings look like different issues; should
they become bothering I recommend opening new reports.

Assigning to Martin, 'cause I'd like him to read my comment
of 2003-10-03 12:17 before I check anything in (we missed
2.3.2, and I don't think 2.3.3 will be for a while).

Logged In: YES 
user_id=21627

I agree it is a hack. Without testing anything right know, I
think all configure tests should run with BASECFLAGS.

Logged In: YES 
user_id=6656

Agree that would be nice, but how do you do arrange for that
for the tests run by, e.g., AC_CHECK_FUNCS?  Seems to me you
have to add it to CFLAGS to make that happen...

Logged In: YES 
user_id=21627

Yes, setting CFLAGS appears to be the only way to achieve that.

There is also the issue of the user setting CFLAGS before
configure starts; traditionally, these should get
incorporated into both configure tests, and the final build
process. So something like

# early
BASECFLAGS=$CFLAGS

# after each block changing either BASECFLAGS or OPT
CFLAGS=$BASECFLAGS $OPT

might work (unless the user selects a flag that contradicts
with one set in BASECFLAGS)

Logged In: YES 
user_id=6656

Something like the attached?  It's impressively vile, but it
doesn't seem to break anything on linux.

I'm not quite sure what gyrations people expect this
machinery to withstand, though...

Logged In: YES 
user_id=21627

eurosys, can you confirm that config-hack-2.diff fixes your
problem as well?

I recommend integration of that change in both 2.4 and 2.3;
if it causes problems on some system, we should have time
before 2.3.3 to correct them.

Logged In: YES 
user_id=878033

Alas,

I cannot confirm this one. See the attached output.

No activity since late 2003.  Do we even have a SCO
system to test anything on?  Should SCO support be
dropped?

Skip says:

"No activity since late 2003.  Do we even have a SCO
system to test anything on?  Should SCO support be
dropped?"

I don't know the answers, but will close this one soon, unless arguments
for keeping open are voiced.