This patch complies with the following request found
near the top of configure.in:

# This is for stuff that absolutely must end up in pyconfig.h.
# Please use pyport.h instead, if possible.

I tested this patch under Cygwin, Win32, and Red
Hat Linux.  Python built and ran successfully on
each of these platforms.

Logged In: YES 
user_id=21627

Sounds good; please install this patch.

Logged In: YES 
user_id=86216

Committed as:

configure 1.306
configure.in 1.316
pyconfig.h.in 1.34
Include/Python.h 2.47
Include/pyport.h 2.48

Logged In: YES 
user_id=21627

How did you test this patch? When I build Python on Linux, I
get tons of error messages

In file included from /usr/include/limits.h:152,
                 from
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117,
                 from
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7,
                 from
/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11,
                 from Include/Python.h:28,
                 from Python/frozenmain.c:4:
/usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined

which come from pyport.h being included before limits.h.

Backing the patch out; try again.

Logged In: YES 
user_id=86216

> How did you test this patch?

I tested under Red Linux 7.1 configured
with "--enable-shared". Note that my version of gcc is
different than yours:

$ gcc --version
2.96

> which come from pyport.h being included before limits.h.

I was concerned about moving where pyport.h is included.
I should have made this concern explicit.

> Backing the patch out;

No problem -- sorry for the trouble.

> try again.

Should I leave the #include "pyport.h" in its
original location and move the DL_IMPORT stuff
after it? Or, should I just try moving #include
"pyport.h" to right after the #include <limits.h>?

Since I can't reproduce the problem, I'm afraid that
my next attempt may cause problems too.  Would you
be willing to retry my first patch and just move the
#include "pyport.h" below the #include <limits.h>?

Logged In: YES 
user_id=21627

Can you please explain why moving pyport.h is necessary?

Logged In: YES 
user_id=86216

> Can you please explain why moving pyport.h is necessary?

It's not. It seemed cleaner, albeit riskier.

Attached is the second version of my patch. It's identical
to the first version except for the Include/Python.h hunk.
The changes to Include/Python.h leave the
#include "pyport.h" in its original location. Instead, I moved
the DL_IMPORT stuff to after the #include "pyport.h".

I tested under Cygwin, Win32, and Linux (i.e., gcc 2.96)
again without any problems. Please test under your Linux
environment. If successful, should we have others test
on other platforms to prevent a repeat of this "fiasco?"

Logged In: YES 
user_id=86216

Any status Martin?  Or, is it one strike and you're out? :,)

Did you get a chance to try the latest patch under your
Linux environment?

Logged In: YES 
user_id=21627

The patch is fine now (tested on Linux and Windows/MSVC),
please apply it.

There is a convention on assigning patches: the patch should
always be assigned to whoever needs to act on it next. So
after uploading the revised patch, you should have assigned
it back to me - that has the effect of the patch showing up
in sf.net/my.

Logged In: YES 
user_id=86216

Committed as:

configure 1.310
configure.in 1.320
pyconfig.h.in 1.37
Include/Python.h 2.50
Include/pyport.h 2.50

> There is a convention on assigning patches: the patch
> should always be assigned to whoever needs to act
> on it next. So after uploading the revised patch,
> you should have assigned it back to me - that has
> the effect of the patch showing up in sf.net/my.

Ah! Sorry, I'll start thinking as developer instead of a
patch submitter...