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.

Author loewis
Recipients
Date 2001-12-11.00:05:10
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2007-08-23 13:57:53adminlinkissue490453 messages
2007-08-23 13:57:53admincreate