(pass non-null argument to pthread_create). 2.2.1 candidate.

    [ #417634 ] configuring without C++ compiler name

by checking that we're not about to try to compile C++ files with "yes".

Now we wait for the system where the C++ compiler *is* called yes...

as OSX HFS+) and if so add an extension to the python executable, but
only in the build directory, not on the installed python.

This should probably go into NEWS (who's responsible for that?).

This is the Unix portion of the fix for SF bug #489052.

Fixes #485679.

used the default Darwin/* for the old code. Reversed those tests so
that compatibility code is in a switch leg with a specific version and
newer systems take the default leg.

This should allow Python to build on OSX 10.1.1 (which jumps from Darwin/1.4
to Darwin/5.1 due to a new numbering scheme).

in http://mail.python.org/pipermail/python-dev/2001-November/018473.html

routines. As of 10.1 using Carbon will crash Python if no window server is
available (ssh connection, console mode, MacOSX Server). This fixes bug
#466907.

A result of this mod is that the default 8bit encoding on OSX is now ASCII,
for the time being. Also, the extension modules that need the Carbon
framework now explicitly include it in setup.py.

not properly processing numeric IPv4 addresses. Fixes V5.1 part of #472675.

This fixes SF bug: [ #473491 ] "install -d" doesn't work on HP-UX.

    1. configure doesn't handle HP-UX release numbers
    (e.g., B.11.00), resulting in MACHDEP = "hpuxB".

    2. After checking for wchar.h, configure doesn't
    include it when checking the size of wchar_t.

    (Python 2.2b1 on HP-UX 11.00)

This adds unsetenv to posix, and uses it in the __delitem__ method of
os.environ.

(XXX Should we change the preferred name for putenv to setenv, for
consistency?)

This is a big one, touching lots of files.  Some of the platforms
aren't tested yet.  Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences.  When accessed as a sequence, they behave exactly as
before.  But they also have attributes like st_mtime or tm_year.  The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there).  If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.

(Still missing is a documentation update.)

<grp.h> it seems.  This requires yet another configure test.

to link a C++ main using the C++ compiler. Fixes #472007.

Check for pthread_sigmask before using it. Fixes remaining problem in #470781.

that -Kpthread is supported. Fixes #470781.
Port to autoconf 2.52.

for tigetstr.

Contributed by Albert Chin in discussion of bug #210665.

Apply patch from "china@thewrittenword.com" to put the correct
location for ld_so_aix in BLDSHARED.

supplied values are the most "normal" or "common" values found for
recent 32 bit machines.  This now seems to work to build Python 2.2
for the ARM processor used on the iPAQ.

Older make's can apparently choke on this.

by bbrox@bbrox.org / lionel.ulmer@free.fr.

This adds a configure check and if all goes well turns on the
PTHREAD_SCOPE_SYSTEM thread attribute for new threads.

This should remove the need to add tiny sleeps at the start of threads
to allow other threads to be scheduled.

support on Linux (and Solaris, I expect) for real.
The necessary symbols are defined once and for all,
under the assumption that they won't harm elsewhere.

out of the box on OSX 10.1. Untested by me (except for not having adverse
effects on 10.0.4) but it looks good, for now. Eventually we should not
trigger on the darwin version but test for something, but until I have
the time to install 10.1 myself I have no clue what to test on.

It would be nice if this got in to the 2.2a3 distribution.

I don't know what difference it makes, but '/' indeed makes less sense
as an include dir than '.', so I'm changing the default.  Just so I
can close the bug. ;-)

I believe this works on Linux (tested both on a system with large file
support and one without it), and it may work on Solaris 2.7.

The changes are twofold:

(1) The configure script now boldly tries to set the two symbols that
    are recommended (for Solaris and Linux), and then tries a test
    script that does some simple seeking without writing.

(2) The _portable_{fseek,ftell} functions are a little more systematic
    in how they try the different large file support options: first
    try fseeko/ftello, but only if off_t is large; then try
    fseek64/ftell64; then try hacking with fgetpos/fsetpos.

I'm keeping my fingers crossed.  The meaning of the
HAVE_LARGEFILE_SUPPORT macro is not at all clear.

I'll see if I can get it to work on Windows as well.