Prev: "undefined symbol: TLSv1_method" error when import psycopg2
Next: Error received from _mechanize.py
From: Ulrich Eckhardt on 14 Oct 2009 04:19
Gabriel Genellina wrote:
>> #ifdef _DEBUG
>> #undef _DEBUG
>> #include <Python.h>
>> #define _DEBUG
>> #else
>> #include <Python.h>
>> #endif
[...to keep Python from linking against non-existant debug libraries.]
>
> No, don't do that. Just compile your application in release mode.

Why not, does it break anything?

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

From: Gabriel Genellina on 14 Oct 2009 10:13
En Wed, 14 Oct 2009 05:19:06 -0300, Ulrich Eckhardt
<eckhardt(a)satorlaser.com> escribi�:

> Gabriel Genellina wrote:
>>> #ifdef _DEBUG
>>> #undef _DEBUG
>>> #include <Python.h>
>>> #define _DEBUG
>>> #else
>>> #include <Python.h>
>>> #endif
> [...to keep Python from linking against non-existant debug libraries.]
>>
>> No, don't do that. Just compile your application in release mode.
>
> Why not, does it break anything?

You have to ensure the same block is used everywhere <Python.h> is
included, or remember to always use "mypython.h", but there is still the
risk when adding some other external library.
The object layout is different in a debug build, and there are other
incompatible differences. Mixing code compiled in both modes hopefully
would generate a linker error, but if not, it may crash the application.
The debug flag for Python *should* be decoupled from the debug flag for
the application embedding it, but unfortunately it isn't. There is a
feature request at http://bugs.python.org (the site doesn't work for me
now)

--
Gabriel Genellina

First  |  Prev  | 
Pages: 1 2
Prev: "undefined symbol: TLSv1_method" error when import psycopg2
Next: Error received from _mechanize.py