On Fri, Jan 19, 2001 at 12:11:02PM -0800, Mark Hammond wrote: > > you can compile the module as C++, but that's also a bit painful... > > My understanding is that the C std doesn't guarantee the order of static > object initialization, whereas C++ does provide these semantics. At least > that is the excuse I found when digging into this some years ago. True, but when PyWhatever_Type is initialized, &PyType_Type ought to be ready (even if it isn't initialized). Heck, &PyType_Type points into the Python core which is *definitely* loaded by that point. Now, if "initialization" also means "relocation to a specific address" then I can understand. Hrm... I've just spent some time with the Windows SDK docs, and I can't find anything that really discusses the problem and resolution. There certainly isn't any warning about "don't do this." It all talks about how fixups are stored with the DLL, how you can optionally use BIND to pre-bind the values, blah blah blah. But nothing saying "it doesn't work." It would be interesting to know more about the actual symptoms that appears when the ob_type init is performed by the structure (rather than at runtime). What happens? Bad address? NULL value? Failure to resolve and load? Is PyType_Type not exported correctly or something? Cheers, -g -- Greg Stein, http://www.lyra.org/
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