Should Python compile as C++?
I'm currently doing a native mingw32 port of Python, and I've hit the ugly "initializer is not a constant" problem mentioned in the FAQ. Hmm, looks like I have three options: 1 Fix the Python sources in the Object/ directory and initalize the structs in a seperate init_objects function 2 compile Python with a C++ compiler 3 fix the mingw32 compiler When trying option 2, I recognized that a lot of Python's source is not valid ANSI C++. There are even variable names like "class" and "new". There are of course less obvious issues when trying to make the source compile as C++, in particular a lot more casts are needed. If it's just that Python is supposed to compile as C++ but it hasn't been tested for a while, I could do the necessary fixes and submit a patch. But if that's a new idea, I don't know if fixing it now makes sense. Because I plan to submit the required changes as a patch when the port is ready, I'd like to know if you'd accept a patch for option #1. Gerhard -- This sig powered by Python! Außentemperatur in München: 6.1 °C Wind: 4.0 m/s
Sounds to me like the Mingw32 compiler is not ANSI compatible. I don't want to have to change the source to accommodate a broken compiler that a very small minority of users want to use. So I am against #1. We never said that our .c files would be valid C++ (.h files is a different story) so I think #2 is not an option. I vote for #3 -- if enough software can't compiled with mingw32 the compiler will be fixed, as it should, and I'm happy to help encourage this. --Guido van Rossum (home page: http://www.python.org/~guido/)
Le 05/02/02 à 01:34, Guido van Rossum écrivit:
I now found the reason for the compiler message. I forgot to set USE_DL_EXPORT when compiling the Python core. Doh! Sorry for the noise. Everything works reasonably fine now.
We never said that our .c files would be valid C++ (.h files is a different story) [...]
Ok. I must have mistaken Python with a different project.
I'm not quite sure if was really a bug in mingw32, but the fact that the compiler accepts the code when compiled as C++ is at least inconsistent. Gerhard -- This sig powered by Python! Außentemperatur in München: 10.2 °C Wind: 3.6 m/s
IIRC, msvc has the exact same problem, and that is turns out that the error is actually correct. <jeez I hate saying anything like this when I know Tim is listening :)> I believe the problem is that C does not guarantee the initialization order of static objects across object modules. The Python idiom of taking the address of a global variable in one module to initialize another global variable in another module is not guaranteed to do what you expect. OTOH, C++ does make such a guarantee. The good news is that if msvc has the same problem, wherever the blame lies, you can be fairly sure that something will be done so msvc works (and has indeed been done for a few modules). Therefore you get mingw for free :) Or-something-like-that ly, Mark.
Mark Hammond wrote:
If the initialization of type objects is all that needs fixing to get Python compile to on MinGW32, why not simply fix it ? MSVC has had the same problem for years. What's strange is that in some cases, MSVC does seem to get it right where in others it fails with an error -- probably a DLL vs. EXE thing. Or am I missing something here :-? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
If the initialization of type objects is all that needs fixing to get Python compile to on MinGW32, why not simply fix it ?
Gerhard indicated all is working now.
It is a problem for extension modules. Object files in the core DLL have no problem, but object modules in seperate extension DLLs that reference the global in pythonxx.dll generate the error. Thus, we see the error as modules are split out of the core - eg, _socket, _winreg, etc. Mark.
MS C can't handle cross-DLL references in initializers, because they're truly not "constant" in the way C requires (but C doesn't say anything about DLLs!). C++'s initialization model is much more liberal (and correspondingly more elaborate and expensive), and C++ can handle cross-DLL references in initializers. MSVC plays both according to reasonable readings of the respective languages' rules.
On Tuesday, February 5, 2002, at 01:31 , Tim Peters wrote: >> ... >> MSVC has had the same problem for years. What's strange is that in some >> cases, MSVC does seem to get it right where in others it fails with an >> error -- probably a DLL vs. EXE thing. > > MS C can't handle cross-DLL references in initializers, because they're > truly not "constant" in the way C requires (but C doesn't say anything > about > DLLs!). I've always understood that the problem here was that Microsoft's object file format allows for patching up references in the text segment but not in the data segment. And C++ doesn't have the problem, because it can do initializers in code anyway, so it doesn't need a data segment reference to the symbol from the DLL. > -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Static initializers in C++ are much more liberal than in C, without the latter's "constant expression" limitations. This follows from that you couldn't declare a static object of an arbitrary class otherwise: C++ has to be prepared to execute any code whatsoever in order to run user-coded constructors. OTOH, because C++ is much more liberal in this respect, order of module initialization is a much worse problem in C, and C++ doesn't define that any more than C does. Some of the worst debugging problems I ever had in C++ were tracking down quiet assumptions about initialization order that didn't hold x-platform. There are a number of well-known hacks in the C++ world for worming around this, some of which explain why starting a large C++ program can give your disk a major workout. As to making Python source compilable under C++, I quietly nudge it in that direction. If I explained why, it wouldn't be quiet anymore <wink>.
Sounds to me like the Mingw32 compiler is not ANSI compatible. I don't want to have to change the source to accommodate a broken compiler that a very small minority of users want to use. So I am against #1. We never said that our .c files would be valid C++ (.h files is a different story) so I think #2 is not an option. I vote for #3 -- if enough software can't compiled with mingw32 the compiler will be fixed, as it should, and I'm happy to help encourage this. --Guido van Rossum (home page: http://www.python.org/~guido/)
Le 05/02/02 à 01:34, Guido van Rossum écrivit:
I now found the reason for the compiler message. I forgot to set USE_DL_EXPORT when compiling the Python core. Doh! Sorry for the noise. Everything works reasonably fine now.
We never said that our .c files would be valid C++ (.h files is a different story) [...]
Ok. I must have mistaken Python with a different project.
I'm not quite sure if was really a bug in mingw32, but the fact that the compiler accepts the code when compiled as C++ is at least inconsistent. Gerhard -- This sig powered by Python! Außentemperatur in München: 10.2 °C Wind: 3.6 m/s
IIRC, msvc has the exact same problem, and that is turns out that the error is actually correct. <jeez I hate saying anything like this when I know Tim is listening :)> I believe the problem is that C does not guarantee the initialization order of static objects across object modules. The Python idiom of taking the address of a global variable in one module to initialize another global variable in another module is not guaranteed to do what you expect. OTOH, C++ does make such a guarantee. The good news is that if msvc has the same problem, wherever the blame lies, you can be fairly sure that something will be done so msvc works (and has indeed been done for a few modules). Therefore you get mingw for free :) Or-something-like-that ly, Mark.
Mark Hammond wrote:
If the initialization of type objects is all that needs fixing to get Python compile to on MinGW32, why not simply fix it ? MSVC has had the same problem for years. What's strange is that in some cases, MSVC does seem to get it right where in others it fails with an error -- probably a DLL vs. EXE thing. Or am I missing something here :-? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
If the initialization of type objects is all that needs fixing to get Python compile to on MinGW32, why not simply fix it ?
Gerhard indicated all is working now.
It is a problem for extension modules. Object files in the core DLL have no problem, but object modules in seperate extension DLLs that reference the global in pythonxx.dll generate the error. Thus, we see the error as modules are split out of the core - eg, _socket, _winreg, etc. Mark.
MS C can't handle cross-DLL references in initializers, because they're truly not "constant" in the way C requires (but C doesn't say anything about DLLs!). C++'s initialization model is much more liberal (and correspondingly more elaborate and expensive), and C++ can handle cross-DLL references in initializers. MSVC plays both according to reasonable readings of the respective languages' rules.
On Tuesday, February 5, 2002, at 01:31 , Tim Peters wrote: >> ... >> MSVC has had the same problem for years. What's strange is that in some >> cases, MSVC does seem to get it right where in others it fails with an >> error -- probably a DLL vs. EXE thing. > > MS C can't handle cross-DLL references in initializers, because they're > truly not "constant" in the way C requires (but C doesn't say anything > about > DLLs!). I've always understood that the problem here was that Microsoft's object file format allows for patching up references in the text segment but not in the data segment. And C++ doesn't have the problem, because it can do initializers in code anyway, so it doesn't need a data segment reference to the symbol from the DLL. > -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Static initializers in C++ are much more liberal than in C, without the latter's "constant expression" limitations. This follows from that you couldn't declare a static object of an arbitrary class otherwise: C++ has to be prepared to execute any code whatsoever in order to run user-coded constructors. OTOH, because C++ is much more liberal in this respect, order of module initialization is a much worse problem in C, and C++ doesn't define that any more than C does. Some of the worst debugging problems I ever had in C++ were tracking down quiet assumptions about initialization order that didn't hold x-platform. There are a number of well-known hacks in the C++ world for worming around this, some of which explain why starting a large C++ program can give your disk a major workout. As to making Python source compilable under C++, I quietly nudge it in that direction. If I explained why, it wouldn't be quiet anymore <wink>.
participants (6)
-
Gerhard Häring -
Guido van Rossum -
Jack Jansen -
M.-A. Lemburg -
Mark Hammond -
Tim Peters