This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: OpenUNIX 8: No Compile/Run
Type: Stage:
Components: Build Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: gvanrossum, ler, loewis
Priority: normal Keywords:

Created on 2001-12-07 23:02 by ler, last changed 2022-04-10 16:04 by admin. This issue is now closed.

File name Uploaded Description Edit
make.out ler, 2001-12-10 20:06
make.out ler, 2001-12-10 20:06 Make output
Messages (11)
msg8063 - (view) Author: Larry Rosenman (ler) Date: 2001-12-07 23:02
On OpenUNIX 8, nothing seems to compile.  Y''ou seem to use ld instead 
of cc for building the shared objects, which is wrong. Also, there 
seems to be other issues with symbol referencing errors.  I've 
given accounts on my box before, and I'm willing to do that again.  I 
believe there are serious issues with this build.  (2.1.1 of 
Python, BTW). 
msg8064 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-12-07 23:06
Logged In: YES 

Thanks for the offer. I don't have time to sort this out,
but maybe someone else who reads these notes does. (What
*IS* OpenUNIX 8???)

You can also try to resolve this yourself -- the configure
script has a few case statements on the platform where it
sets the various compilers and linkers (and their options)
used for various actions. A patch would be most appreciated.

You might also consider trying Python 2.2b2, which has
somewhat improved the build procedure.
msg8065 - (view) Author: Larry Rosenman (ler) Date: 2001-12-07 23:09
Logged In: YES 

OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1.  It is from Caldera.  I' 
ll try and figure it out, but... 

I believe loewis has the ID/PW for an 
account on my box ( []), and I'll 
gladly make more if you folks want. 

msg8066 - (view) Author: Larry Rosenman (ler) Date: 2001-12-10 19:56
Logged In: YES 

Ok, 2.2b2 is *MUCH* better on this platform.  the _socket extension 
doesn't compile.  (EAI_MAX is not defined, and some other issues).  I am 
not sure where this is supposed to be defined. 

I am *STILL* willing to 
allow a python developer (or developers) access to my box. 

msg8067 - (view) Author: Larry Rosenman (ler) Date: 2001-12-10 20:04
Logged In: YES 

Here is a make.out from a  ./configure --with-cxx=CC --with-threads --disable-
msg8068 - (view) Author: Larry Rosenman (ler) Date: 2001-12-10 20:06
Logged In: YES 

Here is the file
msg8069 - (view) Author: Larry Rosenman (ler) Date: 2001-12-10 22:20
Logged In: YES 

More information: the getaddrinfo configure test doesn't take into 
account ---disable--ipv6.  This causes the program to fail, which causes us 
to NOT believe we have getaddrinfo (which we DO). 

If I force 
HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine.  

we still coredump on a make test (I haven't figured that out yet). 

What can 
I do to help this situation?

msg8070 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-12-11 00:05
Logged In: YES 

In 2.1, it is not surprising that OpenUNIX uses ld to link,
since the system is unknown to configure - if vendors rename
their system, they cannot expect that everything continues
to work. Support for OpenUNIX* was added before 2.2b1.

On getaddrinfo, it appears that the implementation has a
bug: Compiling

produces an error message "fail 11", which indicates that
the getnameinfo does return "::" for AI_PASSIVE, but fails
to return "::1" (i.e. localhost) without AI_PASSIVE. The
test above is the test that tells Python not to use the
system getaddrinfo.

The EAI_MAX problem is the same that was reported in #490453
 (since BSDI shows the same getaddrinfo bug), and has been
fixed in the CVS.

The coredump is produced by test_largefile, when it tries to
write a byte into a large file offset. It uses write(2) to
do so, and receives the signal SIGXFSZ (RLIMIT_FSIZE
exceeded), which causes a core dump. I think that can be
worked-around by ignoring SIGXFSZ where available; the
system call will in turn return  EFBIG, which in turn will
raise an IOError, which will lead test_largefile to think
that large files are not supported.

In addition, test_unicodefile fails, since the system
encoding is not known; this is not a serious problem.
msg8071 - (view) Author: Larry Rosenman (ler) Date: 2001-12-11 01:57
Logged In: YES 

I verified that if I enable largefile support we don't
coredump any more (I'll leave largfiles enabled on /home). 

as to the getaddrinfo issue, should I report this to

Thanks for looking at it. 

msg8072 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-12-11 18:18
Logged In: YES 

The largefile problem was fixed with 1.12;
I can't test it since it won't send the signal anymore (but
I think it should work now - or, rather, the test will fail
instead of dumping core).

The test_unicodefile also seems to be due to a bug in
OpenUNIX: nl_langinfo(CODESET) returns an empty string in
the "C" locale. I believe it should return the name of the
charset in the C locale, e.g. "US-ASCII" (Solaris returns
"646", Linux 'ansi_x3.4_1968').

On the getaddrinfo issue, please do report this to Caldera:
the test was authored by Jun-ichiro "itojun" Hagino, who is
an IPv6 guru - so I'm pretty certain the test is right and
the system is wrong. However, if Caldera analyses this as a
bug on our side, please let us know.

With that, I think all issues have been addressed, so I'm
closing this report. If you find any further problems,
please open a new one.
msg8073 - (view) Author: Larry Rosenman (ler) Date: 2001-12-11 18:49
Logged In: YES 

I turned off largefile support, and the test 

test test_largefile skipped -- filesystem does 
not have largefile

I also reported both OU8 bugs to caldera.
Date User Action Args
2022-04-10 16:04:44adminsetgithub: 35696
2001-12-07 23:02:39lercreate