I.e. even with the change, it would *still* depend on objimpl.h
(and other) settings what ABI this debug DLL exactly has.
I think it does. My proposal was perhaps not clear: For existing
python versions, always export _PyObject_DebugMalloc et al.
Hmm. That's still not clear. What are "exist
> -Original Message-
> From: "Martin v. Löwis" [mailto:mar...@v.loewis.de]
> Sent: 15. júní 2010 21:20
> To: Kristján Valur Jónsson
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] debug and release python
>
> Am 15.06.2010 14:48, schrieb Krist
> -Original Message-
> From: Amaury Forgeot d'Arc [mailto:amaur...@gmail.com]
> Sent: 15. júní 2010 21:24
> To: Kristján Valur Jónsson
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] debug and release python
>
> I remember having the
2010/6/14 Kristján Valur Jónsson :
> Hello there.
>
> I‘m sure this has come up before, but here it is again:
>
>
>
> Python exports a different api in debug mode, depending on whether
> PYMALLOC_DEBUG and WITH_PYMALLOC are exported. This means that _d.pyd files
> that are used must have been comp
Am 15.06.2010 14:48, schrieb Kristján Valur Jónsson:
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.
-dev@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, ther
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
___
