[Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 11 Dec 2001 10:49:21 -0800
Bugs item #490453, was opened at 2001-12-07 15:02
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470
Category: Build
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Larry Rosenman (ler)
Assigned to: Martin v. Löwis (loewis)
Summary: OpenUNIX 8: No Compile/Run
Initial Comment:
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).
----------------------------------------------------------------------
>Comment By: Larry Rosenman (ler)
Date: 2001-12-11 10:49
Message:
Logged In: YES
user_id=36452
I turned off largefile support, and the test
works.
test_largefile
test test_largefile skipped -- filesystem does
not have largefile
support
I also reported both OU8 bugs to caldera.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-12-11 10:18
Message:
Logged In: YES
user_id=21627
The largefile problem was fixed with test_largefile.py 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.
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-10 17:57
Message:
Logged In: YES
user_id=36452
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
caldera?
Thanks for looking at it.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-12-10 16:05
Message:
Logged In: YES
user_id=21627
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
http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=13988&aid=486099
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.
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-10 14:20
Message:
Logged In: YES
user_id=36452
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?
LER
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-10 12:06
Message:
Logged In: YES
user_id=36452
Here is the file
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-10 12:04
Message:
Logged In: YES
user_id=36452
Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable-
ipv6
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-10 11:56
Message:
Logged In: YES
user_id=36452
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.
LER
----------------------------------------------------------------------
Comment By: Larry Rosenman (ler)
Date: 2001-12-07 15:09
Message:
Logged In: YES
user_id=36452
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 (lerami.lerctr.org [207.158.72.11]), and I'll
gladly make more if you folks want.
Larry
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-07 15:06
Message:
Logged In: YES
user_id=6380
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.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470