| msg18477 - (view) |
Author: Roger Erens (eurosys) |
Date: 2003-10-01 10:31 |
| 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 "", 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 |
|
|
| msg18478 - (view) |
Author: Anthony Baxter (anthonybaxter)  |
Date: 2003-10-01 14:43 |
| 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. |
|
|
| msg18479 - (view) |
Author: Michael Hudson (mwh)  |
Date: 2003-10-01 15:10 |
| Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. |
|
|
| msg18480 - (view) |
Author: Anthony Baxter (anthonybaxter) |
Date: 2003-10-01 15:34 |
| 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? |
|
|
| msg18481 - (view) |
Author: Roger Erens (eurosys) |
Date: 2003-10-01 15:45 |
| Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- |
|
|
| msg18482 - (view) |
Author: Michael Hudson (mwh) |
Date: 2003-10-01 16:19 |
| 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?) |
|
|
| msg18483 - (view) |
Author: Roger Erens (eurosys) |
Date: 2003-10-02 22:25 |
| 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 |
|
|
| msg18484 - (view) |
Author: Michael Hudson (mwh) |
Date: 2003-10-03 11:17 |
| 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... |
|
|
| msg18485 - (view) |
Author: Roger Erens (eurosys) |
Date: 2003-10-03 12:37 |
| 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 |
|
|
| msg18486 - (view) |
Author: Michael Hudson (mwh) |
Date: 2003-10-03 12:49 |
| 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). |
|
|
| msg18487 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-10-03 13:26 |
| 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. |
|
|
| msg18488 - (view) |
Author: Michael Hudson (mwh) |
Date: 2003-10-03 13:37 |
| 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... |
|
|
| msg18489 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-10-03 14:09 |
| 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) |
|
|
| msg18490 - (view) |
Author: Michael Hudson (mwh) |
Date: 2003-10-03 14:20 |
| 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... |
|
|
| msg18491 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-10-03 17:22 |
| 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. |
|
|
| msg18492 - (view) |
Author: Roger Erens (eurosys) |
Date: 2003-10-08 08:30 |
| Logged In: YES user_id=878033 Alas, I cannot confirm this one. See the attached output. |
|
|
| msg55407 - (view) |
Author: Skip Montanaro (skip.montanaro) * |
Date: 2007-08-29 01:54 |
| No activity since late 2003. Do we even have a SCO system to test anything on? Should SCO support be dropped? |
|
|
| msg82023 - (view) |
Author: Daniel Diniz (ajaksu2) * |
Date: 2009-02-14 12:09 |
| 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. |
|
|