MSVC 6.0 Unsupported?

[Syver Enstad]

I've downloaded both source distro, and binary installer. Installed
python with the binary installer, when I attempted to compile
mxDateTime (mxBase) for 2.3 with MSVC 6.0 I got an error that seemed
related to forward declarations.

It seems that the #defines that makes staticforward into extern when
using the MSVC 6 compiler has been removed from object.h. So I guess
this means I should use VC++ 7.0 to compile python with?


--

Vennlig hilsen

Syver Enstad

[Martin v. Löwis]

Syver Enstad <sy*************@online.no> writes:

It seems that the #defines that makes staticforward into extern when
using the MSVC 6 compiler has been removed from object.h. So I guess
this means I should use VC++ 7.0 to compile python with?

That assumption is definitely wrong. If VC6 fails to compile some
code, it is likely a problem in that code, not in Python.

Regards,
Martin

[M.-A. Lemburg]

Gerhard Häring wrote:

Syver Enstad wrote:

I've downloaded both source distro, and binary installer. Installed
python with the binary installer, when I attempted to compile
mxDateTime (mxBase) for 2.3 with MSVC 6.0 I got an error that seemed
related to forward declarations.

It seems that the #defines that makes staticforward into extern when
using the MSVC 6 compiler has been removed from object.h. So I guess
this means I should use VC++ 7.0 to compile python with?
Huh? You couldn't be more wrong.

1) Python 2.3 binaries *are* built with MSVC6

2) staticforward was defined from exten to empty on win32 for Python 2.3

.... and that's the problem: MS VC6 doesn't work with static
forwards. Previous Python versions therefore defined a macro
called BAD_STATIC_FORWARD which triggered a work-around in
Python.

That work-around was removed in Python 2.3 for some reason
I don't understand (and I just stumbled over it when I tried
to compile egenix-mx-base against Python 2.3 on Windows --
we do regular builds against the Python 2.3 on Linux and gcc
does not botch the static forwards, so we didn't see the
problem before the Python 2.3 release).
3) The quick hack I used is to insert something like:

#ifdef _MSC_VER
#define staticforward extern
#endif

in the relevant source files *after* they include Python.h.
The best thing to do is to replace this code in Python's object.h
file (Python23\Include\object.h; note the comment !):

/*
Define staticforward and statichere for source compatibility with old
C extensions.

The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers.
(In fact, we expect that the compilers are all fixed eight years later.)
*/

#define staticforward static
#define statichere static

with this snippet (the previously used one):

/*
A common programming style in Python requires the forward declaration
of static, initialized structures, e.g. for a type object that is used
by the functions whose address must be used in the initializer.
Some compilers (notably SCO ODT 3.0, I seem to remember early AIX as
well) botch this if you use the static keyword for both declarations
(they allocate two objects, and use the first, uninitialized one until
the second declaration is encountered). Therefore, the forward
declaration should use the 'forwardstatic' keyword. This expands to
static on most systems, but to extern on a few. The actual storage
and name will still be static because the second declaration is
static, so no linker visible symbols will be generated. (Standard C
compilers take offense to the extern forward declaration of a static
object, so I can't just put extern in all cases. :-( )
*/

#ifdef BAD_STATIC_FORWARD
#define staticforward extern
#define statichere static
#else /* !BAD_STATIC_FORWARD */
#define staticforward static
#define statichere static
#endif /* !BAD_STATIC_FORWARD */
Anyway you can't compile the eGenix extensions with Python 2.3. I hoped
this gets fixed soon. The compile fails somewhere in the mxTextTools
stuff. All I needed was mxDateTime and I got that to compile.

If you need Windoze binaries, I've uploaded some for the pyPgSQL project
at http://sourceforge.net/project/showf...group_id=16528

pypgsql-experimental

Python 2.3b2 2003-07-17 11:22
egenix-mx-base-2.0.4.win32-py2.3.exe 471273 6 i386
.exe (32-bit Windows)

FYI, we'll release fixed versions later this week.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source (#1, Aug 06 2003)

Python/Zope Products & Consulting ... http://www.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

__________________________________________________ ______________________

[Syver Enstad]

"M.-A. Lemburg" <ma*@lemburg.com> writes:

The best thing to do is to replace this code in Python's object.h
file (Python23\Include\object.h; note the comment !):

That's exactly what I did and it worked fine.

[Gerhard Häring]

Syver Enstad wrote:

"M.-A. Lemburg" <ma*@lemburg.com> writes:

The best thing to do is to replace this code in Python's object.h
file (Python23\Include\object.h; note the comment !):

That's exactly what I did and it worked fine.

Requiring users of my software to patch their Python instalation is not
an option for me.

-- Gerhard

[Syver Enstad]

Gerhard Häring <[e-mail]> writes:

Syver Enstad wrote:

"M.-A. Lemburg" <ma*@lemburg.com> writes:

The best thing to do is to replace this code in Python's object.h
file (Python23\Include\object.h; note the comment !):

That's exactly what I did and it worked fine.

Requiring users of my software to patch their Python instalation is
not an option for me.

But Gerhard, what can I do? Every python extension that I will try to
compile will fail if it depends on a working staticforward. The most
rational thing to me is to patch object.h instead of patching every
..cpp/.c file that needs this define.

--

Vennlig hilsen

Syver Enstad

[Gerhard Häring]

Syver Enstad wrote:

Gerhard Häring <[e-mail]> writes:

Syver Enstad wrote:

"M.-A. Lemburg" <ma*@lemburg.com> writes:
The best thing to do is to replace this code in Python's object.h
file (Python23\Include\object.h; note the comment !):

That's exactly what I did and it worked fine.

Requiring users of my software to patch their Python instalation is
not an option for me.

But Gerhard, what can I do? Every python extension that I will try to
compile will fail if it depends on a working staticforward. The most
rational thing to me is to patch object.h instead of patching every
.cpp/.c file that needs this define.

Yeah sure. That's the best option for *you* if you want existing
(noncompatible) Python extensions :)

I was playing the side of an author of Open Source Software that should
be buildable with Python 2.3 and MSVC6. That's where my different view
on this issue comes from :-)

-- Gerhard

[Bryan]

"Syver Enstad" <sy*************@online.no> wrote in message news:u4***********@online.no...

Gerhard Häring <[e-mail]> writes:

Syver Enstad wrote:

"M.-A. Lemburg" <ma*@lemburg.com> writes:

>The best thing to do is to replace this code in Python's object.h
>file (Python23\Include\object.h; note the comment !):
That's exactly what I did and it worked fine.

Requiring users of my software to patch their Python instalation is
not an option for me.

But Gerhard, what can I do? Every python extension that I will try to
compile will fail if it depends on a working staticforward. The most
rational thing to me is to patch object.h instead of patching every
.cpp/.c file that needs this define.

--

Vennlig hilsen

Syver Enstad

syver,

i agree, patching object.h is the only rational thing to do... everyone in my company will do the same. i'm using pyrex and
everytime i regenerate the c file, i need to repatch the intermediate c file. i got tired of this so i just patched object.h and
now i this issue is gone. i'm not sure if there is a better (more convenient) way. it was this way before 2.3 and everything
worked just fine, so there shouldn't be any harm doing this in 2.3. i feel it was taken out for political reasons when it should
have been left in for technical reasons. after all, the windows verson of python at www.python.org is compiled in msvc. so
obviously the python community accepts msvc as an exceptable compiler on windows. care should have been taken to be more
accomodating.

bryan

[Irmen de Jong]

Syver Enstad wrote:

But Gerhard, what can I do? Every python extension that I will try to
compile will fail if it depends on a working staticforward. The most
rational thing to me is to patch object.h instead of patching every
.cpp/.c file that needs this define.

Can't you just add a single compiler option (for cl.exe) to your project?

/Dstaticforward=extern

wouldn't that work?

--Irmen

[Syver Enstad]

Irmen de Jong <[e-mail]> writes:

Syver Enstad wrote:

But Gerhard, what can I do? Every python extension that I will try

to

compile will fail if it depends on a working staticforward. The most

rational thing to me is to patch object.h instead of patching every
.cpp/.c file that needs this define.

Can't you just add a single compiler option (for cl.exe) to your
project?
/Dstaticforward=extern

Isn't it bad form to define a macro twice? This macro is alreay
defined in object.h, and we define it once again on the command
line.
--

Vennlig hilsen

Syver Enstad