What I mean is that a third party software vendor supplies a foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll and python2x_d.dll respectively. But the latter will have been compiled to match a certain settings of the objimpl.h header, which may not match whatever is being used to build the local python2x_d.dll. And thus, you get strange and hard to debug linker errors when trying to load external libraries. When developing superapp.exe, which uses a custom build of python2x, perhaps even embedded, python2x_d.dll is used extensively both during the development process and the testing process. This is why foobarapp_d.pyd is necessary and why it is supplied by any sensible vendor providing opaque python extensions. But the current objimpl.h api makes it a matter of developer choice whether that foobarapp_d.pyd will successfully link with your python2x_d.dll or not. IMHO, it is not good practice to expose an API that changes depending on preprocessor settings like this. K > -----Original Message----- > From: "Martin v. Löwis" [mailto:martin at v.loewis.de] > Sent: 14. júní 2010 22:13 > To: Kristján Valur Jónsson > Cc: python-dev at python.org > Subject: Re: [Python-Dev] debug and release python > > > Some external software comes with proprietary .pyd bindings. > > Can you please explain what a "proprietary .pyd binding" is? > > Do you mean they come with extension modules? If so, there is no chance > of using them in debug mode, anyway, right? So what specifically is the > problem? > > Regards, > Martin
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