Mark Hammond wrote: > > > > 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. > > > > 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. > > 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 :) 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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4