problems with python24_d.lib

[Bob Marinier]

Hi,

I'm wrapping some code for Python on Windows using Visual Studio 2005
(although I think this will all be exactly the same in 6 and 2003).

When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
to be defined).  Something in Python.h, then, tells the linker it needs
python24_d.lib.  The problem is that the Windows installer for Python
does not include this file.  One possible workaround I found on the
Python mailing list is to change the SWIG output so that

#include "Python.h"

becomes:

#ifdef _DEBUG
  #undef _DEBUG
  #include "Python.h"
  #define _DEBUG
#else
  #include "Python.h"
#endif

This "tricks" Python.h into thinking this is not a debug build, and thus
is looks for python24.lib instead, which does exist.  This works, and
since I'm not trying to debug Python, I don't care that I'm not linking
the debug library.  But having to manually change SWIG's output each
time I generate it is a real pain.  Is there either a way to change
SWIG's output to this or does anyone have another idea for how to
workaround this problem?  And no, renaming python24.lib to
python24_d.lib does not work :) (they aren't binary compatible).

Thanks,
Bob Marinier


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Sohail Somani]

> -----Original Message-----
> From: swig-user-bounces@...
> [mailto:swig-user-bounces@...] On Behalf Of
> Bob Marinier
> Sent: Wednesday, June 07, 2006 1:41 PM
> To: swig-user@...
> Subject: [Swig-user] problems with python24_d.lib
>
> Hi,
>
> I'm wrapping some code for Python on Windows using Visual Studio 2005
> (although I think this will all be exactly the same in 6 and 2003).
>
> When I'm doing a debug build, the symbol _DEBUG is defined
> (and it needs
> to be defined).  Something in Python.h, then, tells the
> linker it needs
> python24_d.lib.  The problem is that the Windows installer for Python
> does not include this file.  One possible workaround I found on the
> Python mailing list is to change the SWIG output so that
>
> #include "Python.h"
>
> becomes:
>
> #ifdef _DEBUG
>   #undef _DEBUG
>   #include "Python.h"
>   #define _DEBUG
> #else
>   #include "Python.h"
> #endif

Could you do something like this for debug builds:

cl ... /U_DEBUG /D_REALLY_DEBUG lib_wrap.cc

In lib.i:

%module lib;
%{
#ifdef _REALLY_DEBUG
# define _DEBUG
#endif
%}

Haven't tried it, but maybe it'll work


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

Am Wed, 07 Jun 2006 22:40:37 +0200 hat Bob Marinier  
<rmarinie@...> geschrieben:

> Hi,
>
> I'm wrapping some code for Python on Windows using Visual Studio 2005
> (although I think this will all be exactly the same in 6 and 2003).
>
> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
> to be defined).  Something in Python.h, then, tells the linker it needs
> python24_d.lib.  The problem is that the Windows installer for Python
> does not include this file.  One possible workaround I found on the
> Python mailing list is to change the SWIG output so that
>
> #include "Python.h"
>
> becomes:
>
> #ifdef _DEBUG
>   #undef _DEBUG
>   #include "Python.h"
>   #define _DEBUG
> #else
>   #include "Python.h"
> #endif
>
> This "tricks" Python.h into thinking this is not a debug build, and thus
> is looks for python24.lib instead, which does exist.  This works, and
> since I'm not trying to debug Python, I don't care that I'm not linking
> the debug library.  But having to manually change SWIG's output each
> time I generate it is a real pain.  Is there either a way to change
> SWIG's output to this or does anyone have another idea for how to
> workaround this problem?  And no, renaming python24.lib to
> python24_d.lib does not work :) (they aren't binary compatible).

I had lots of trouble with this either and use the version you pointed  
out. Actually, it stopped working with VS 2005 because VS threw an error  
when it noticed that some header files were compiled with _DEBUG defined  
and some without. So for 2005 I had to fix a header in the python  
installation myself and commented out every #define Py_DEBUG (or similar,  
don't remember exactly). I agree that this solution is really nasty, but  
couldn't find a better way (except compiling the python24_d.lib from  
python source which I don't want to do).
Our build system (SCons) fixes those files automatically and replaces the  
#include "python.h" with the code you showed above every time the wrapper  
is regenerated, so this is not much hassle for us anymore. Just under 2005  
we have to change that nasty python header which is really evil.
Imo this is python's fault though. It shouldn't have those #pragma  
comment(lib, python24_d.lib) in its header. I should tell the program what  
to link to, not the python headers.

If you find a better solution, please post here!

-Matthias



_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Bob Marinier]

Nitro wrote:

> Am Wed, 07 Jun 2006 22:40:37 +0200 hat Bob Marinier
> <rmarinie@...> geschrieben:
>
>> Hi,
>>
>> I'm wrapping some code for Python on Windows using Visual Studio 2005
>> (although I think this will all be exactly the same in 6 and 2003).
>>
>> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
>> to be defined).  Something in Python.h, then, tells the linker it needs
>> python24_d.lib.  The problem is that the Windows installer for Python
>> does not include this file.  One possible workaround I found on the
>> Python mailing list is to change the SWIG output so that
>>
>> #include "Python.h"
>>
>> becomes:
>>
>> #ifdef _DEBUG
>>   #undef _DEBUG
>>   #include "Python.h"
>>   #define _DEBUG
>> #else
>>   #include "Python.h"
>> #endif
>>
>> This "tricks" Python.h into thinking this is not a debug build, and thus
>> is looks for python24.lib instead, which does exist.  This works, and
>> since I'm not trying to debug Python, I don't care that I'm not linking
>> the debug library.  But having to manually change SWIG's output each
>> time I generate it is a real pain.  Is there either a way to change
>> SWIG's output to this or does anyone have another idea for how to
>> workaround this problem?  And no, renaming python24.lib to
>> python24_d.lib does not work :) (they aren't binary compatible).
>
> I had lots of trouble with this either and use the version you pointed
> out. Actually, it stopped working with VS 2005 because VS threw an
> error when it noticed that some header files were compiled with _DEBUG
> defined and some without. So for 2005 I had to fix a header in the
> python installation myself and commented out every #define Py_DEBUG
> (or similar, don't remember exactly). I agree that this solution is
> really nasty, but couldn't find a better way (except compiling the
> python24_d.lib from python source which I don't want to do).
> Our build system (SCons) fixes those files automatically and replaces
> the #include "python.h" with the code you showed above every time the
> wrapper is regenerated, so this is not much hassle for us anymore.
> Just under 2005 we have to change that nasty python header which is
> really evil.
> Imo this is python's fault though. It shouldn't have those #pragma
> comment(lib, python24_d.lib) in its header. I should tell the program
> what to link to, not the python headers.
>
> If you find a better solution, please post here!
>
> -Matthias

That's interesting -- I don't have the problem you describe in VS 2005.  
Maybe I'm just getting lucky somehow.  I'm going to try Sohail's
suggestion, though, since that's easier for me than trying to change the
code after the fact (but if I have to then that's what I'll do).

Bob


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Sohail Somani]

> -----Original Message-----
> From: swig-user-bounces@...
> Imo this is python's fault though. It shouldn't have those #pragma  
> comment(lib, python24_d.lib) in its header. I should tell the
> program what  
> to link to, not the python headers.

Some consider this a feature, I think its just for lazy programmers or
ease-of-use, whichever makes you feel better :)


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Bob Marinier]

Sohail Somani wrote:

-----Original Message-----
From: swig-user-bounces@... 
[swig-user-bounces@...] On Behalf Of 
Bob Marinier
Sent: Wednesday, June 07, 2006 1:41 PM
To: swig-user@...
Subject: [Swig-user] problems with python24_d.lib

Hi,

I'm wrapping some code for Python on Windows using Visual Studio 2005 
(although I think this will all be exactly the same in 6 and 2003).

When I'm doing a debug build, the symbol _DEBUG is defined 
(and it needs 
to be defined).  Something in Python.h, then, tells the 
linker it needs 
python24_d.lib.  The problem is that the Windows installer for Python 
does not include this file.  One possible workaround I found on the 
Python mailing list is to change the SWIG output so that

#include "Python.h"

becomes:

#ifdef _DEBUG
  #undef _DEBUG
  #include "Python.h"
  #define _DEBUG
#else
  #include "Python.h"
#endif
    

Could you do something like this for debug builds:

cl ... /U_DEBUG /D_REALLY_DEBUG lib_wrap.cc

In lib.i:

%module lib;
%{
#ifdef _REALLY_DEBUG
#	define _DEBUG
#endif
%}

Haven't tried it, but maybe it'll work
  

This seems to work great.  The only change I made was to use %runtime %{ ... %} to insert the code because that causes this to appear earlier in the generated code (otherwise is comes after "#include <stdexcept>", which may or may not matter).

Thanks!
Bob


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

> This seems to work great.  The only change I made was to use %runtime %{
> ... %} to insert the code because that causes this to appear earlier in
> the generated code (otherwise is comes after "#include <stdexcept>",
> which may or may not matter).

Won't that approach strip the _DEBUG symbol away from too many headers?  
For example if you #include "myHeader.h" and this header does something  
like #ifdef _DEBUG somewhere, then this won't work all of a sudden. Can  
you still debug through the wrappers (with symbol information and such) if  
_DEBUG is not defined for the parts except python?

-Matthias



_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Bob Marinier]

Nitro wrote:

This seems to work great.  The only change I made was to use %runtime %{
... %} to insert the code because that causes this to appear earlier in
the generated code (otherwise is comes after "#include <stdexcept>",
which may or may not matter).
    

Won't that approach strip the _DEBUG symbol away from too many headers?  
For example if you #include "myHeader.h" and this header does something  
like #ifdef _DEBUG somewhere, then this won't work all of a sudden. Can  
you still debug through the wrappers (with symbol information and such) if  
_DEBUG is not defined for the parts except python?

-Matthias
  

It might -- here's how it gets generated ("..." means lots of stuff I'm skipping):

...
#include <Python.h>
...
#include <string.h>
...
#include <Python.h>
...
#ifdef REALLY_DEBUG
#    define _DEBUG
#endif
...
(everything else)

I don't know why Python.h is included twice (maybe the preprocessor makes sure only one of those is used -- I didn't look into it).  But string.h is the only other header that gets included before _DEBUG is #defined (it's included automatically by SWIG -- everything I specify in my .i file comes later).  However, everything compiles without errors or warnings (in VS 2003 -- I haven't tested this approach with 2005 yet) and I have successfully been able to set breakpoints and step through the generated code, which is what I was after.  There may be a pitfall in this approach, but I haven't stumbled across it yet (then again, you specifically mentioned VS 2005 as being problematic, so I'll be testing that this afternoon).

Bob


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Bob Marinier]

Bob Marinier wrote:

> Nitro wrote:
>>> This seems to work great.  The only change I made was to use %runtime %{
>>> ... %} to insert the code because that causes this to appear earlier in
>>> the generated code (otherwise is comes after "#include <stdexcept>",
>>> which may or may not matter).
>>>    
>>
>> Won't that approach strip the _DEBUG symbol away from too many headers?  
>> For example if you #include "myHeader.h" and this header does something  
>> like #ifdef _DEBUG somewhere, then this won't work all of a sudden. Can  
>> you still debug through the wrappers (with symbol information and such) if  
>> _DEBUG is not defined for the parts except python?
>>
>> -Matthias
>>  
> It might -- here's how it gets generated ("..." means lots of stuff
> I'm skipping):
>
> ...
> #include <Python.h>
> ...
> #include <string.h>
> ...
> #include <Python.h>
> ...
> #ifdef REALLY_DEBUG
> #    define _DEBUG
> #endif
> ...
> (everything else)
>
> I don't know why Python.h is included twice (maybe the preprocessor
> makes sure only one of those is used -- I didn't look into it).  But
> string.h is the only other header that gets included before _DEBUG is
> #defined (it's included automatically by SWIG -- everything I specify
> in my .i file comes later).  However, everything compiles without
> errors or warnings (in VS 2003 -- I haven't tested this approach with
> 2005 yet) and I have successfully been able to set breakpoints and
> step through the generated code, which is what I was after.  There may
> be a pitfall in this approach, but I haven't stumbled across it yet
> (then again, you specifically mentioned VS 2005 as being problematic,
> so I'll be testing that this afternoon).
>
> Bob

I've tested in VS 2005 and everything seems to work fine (no errors or
warnings).

Bob


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Sohail Somani]

> -----Original Message-----
> From: swig-user-bounces@...
> [mailto:swig-user-bounces@...] On Behalf Of Nitro
> Sent: Thursday, June 08, 2006 8:05 AM
> To: Bob Marinier
> Cc: swig-user@...
> Subject: Re: [Swig-user] problems with python24_d.lib
>
> > This seems to work great.  The only change I made was to
> use %runtime %{
> > ... %} to insert the code because that causes this to
> appear earlier in
> > the generated code (otherwise is comes after "#include <stdexcept>",
> > which may or may not matter).
>
> Won't that approach strip the _DEBUG symbol away from too
> many headers?  
> For example if you #include "myHeader.h" and this header does
> something  
> like #ifdef _DEBUG somewhere, then this won't work all of a
> sudden. Can  
> you still debug through the wrappers (with symbol information
> and such) if  
> _DEBUG is not defined for the parts except python?

Like Matt says, this is not guaranteed to work 100%. I think it should
work for python though.


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Bob Marinier]

Sorry to resurrect this old thread:

So I finally ran into the compiler error that Nitro described that
arises when not #define'ing _DEBUG ("You have included some C++/C
library header files with _DEBUG defined and some with _DEBUG not
defined. This will not work correctly. Please have _DEBUG set or clear
consistently.)  It appears that this only comes up if your Visual Studio
project generates code for "Multi-threaded Debug DLL".  Using
"Multi-threaded Debug" does not cause the problem.

It looks like I may have to resort to Nitro's solution, which involves
manually editing python.h -- yuck.

Bob

Sohail Somani wrote:

>> -----Original Message-----
>> From: swig-user-bounces@...
>> [mailto:swig-user-bounces@...] On Behalf Of Nitro
>> Sent: Thursday, June 08, 2006 8:05 AM
>> To: Bob Marinier
>> Cc: swig-user@...
>> Subject: Re: [Swig-user] problems with python24_d.lib
>>
>>    
>>> This seems to work great.  The only change I made was to
>>>      
>> use %runtime %{
>>    
>>> ... %} to insert the code because that causes this to
>>>      
>> appear earlier in
>>    
>>> the generated code (otherwise is comes after "#include <stdexcept>",
>>> which may or may not matter).
>>>      
>> Won't that approach strip the _DEBUG symbol away from too
>> many headers?  
>> For example if you #include "myHeader.h" and this header does
>> something  
>> like #ifdef _DEBUG somewhere, then this won't work all of a
>> sudden. Can  
>> you still debug through the wrappers (with symbol information
>> and such) if  
>> _DEBUG is not defined for the parts except python?
>>    
>
> Like Matt says, this is not guaranteed to work 100%. I think it should
> work for python though.
>
>
> _______________________________________________
> Swig-user mailing list
> Swig-user@...
> https://lists.sourceforge.net/lists/listinfo/swig-user
>  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Hassan Mehmet]

Bob Marinier <rmarinie <at> eecs.umich.edu> writes:

>
> Sorry to resurrect this old thread:
>
> So I finally ran into the compiler error that Nitro described that
> arises when not #define'ing _DEBUG ("You have included some C++/C
> library header files with _DEBUG defined and some with _DEBUG not
> defined. This will not work correctly. Please have _DEBUG set or clear
> consistently.)  It appears that this only comes up if your Visual Studio
> project generates code for "Multi-threaded Debug DLL".  Using
> "Multi-threaded Debug" does not cause the problem.
>
> It looks like I may have to resort to Nitro's solution, which involves
> manually editing python.h -- yuck.
>
> Bob
>
> Sohail Somani wrote:
> >> -----Original Message-----
> >> From: swig-user-bounces <at> lists.sourceforge.net
> >> [mailto:swig-user-bounces <at> lists.sourceforge.net] On Behalf Of Nitro
> >> Sent: Thursday, June 08, 2006 8:05 AM
> >> To: Bob Marinier
> >> Cc: swig-user <at> lists.sourceforge.net
> >> Subject: Re: [Swig-user] problems with python24_d.lib
> >>
> >>    
> >>> This seems to work great.  The only change I made was to
> >>>      
> >> use %runtime %{
> >>    
> >>> ... %} to insert the code because that causes this to
> >>>      
> >> appear earlier in
> >>    
> >>> the generated code (otherwise is comes after "#include <stdexcept>",
> >>> which may or may not matter).
> >>>      
> >> Won't that approach strip the _DEBUG symbol away from too
> >> many headers?  
> >> For example if you #include "myHeader.h" and this header does
> >> something  
> >> like #ifdef _DEBUG somewhere, then this won't work all of a
> >> sudden. Can  
> >> you still debug through the wrappers (with symbol information
> >> and such) if  
> >> _DEBUG is not defined for the parts except python?
> >>    
> >
> > Like Matt says, this is not guaranteed to work 100%. I think it should
> > work for python though.

Hi

I have just run into this same problem when migrating from swig 1.3.29 to
1.3.31

The Lib/python/pyruntime.swg file has changed between releases.

In 1.3.31
---------

%insert(runtime) %{
/* Python.h has to appear first */
#include <Python.h>
%}

In 1.3.29
---------

/*
 The Python header Python.h forces the VC compiler to link against
Python22_d.dll if _DEBUG is set.
 Unfortunately this library is not distributed with standard Python. So, to
allow a debug build of
 the extension module. we undef _DEBUG when including <Python.h>
 */

%insert(runtime) %{
/* Python.h has to appear first */
#ifdef _DEBUG
#   include <stddef.h>
#   include <stdarg.h>
#   include <stdio.h>
#   include <stdlib.h>
#   include <assert.h>
#   include <errno.h>
#   include <ctype.h>
#   include <wchar.h>
#   include <basetsd.h>
#   include <io.h>
#   include <limits.h>
#   include <float.h>
#   include <string.h>
#   include <math.h>
#   include <time.h>
#undef _DEBUG
#include <Python.h>
#define _DEBUG
#else
#include <Python.h>
#endif
%}


I'm not sure how safe this is but my solution was to replace the 1.3.31
pyruntest.swg with 1.3.29's

It appears to work :)

Cheers
Hassan




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[wsfulton]

Bob Marinier wrote:

> Hi,
>
> I'm wrapping some code for Python on Windows using Visual Studio 2005
> (although I think this will all be exactly the same in 6 and 2003).
>
> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
> to be defined).  Something in Python.h, then, tells the linker it needs
> python24_d.lib.  The problem is that the Windows installer for Python
> does not include this file.  One possible workaround I found on the
> Python mailing list is to change the SWIG output so that
>
> #include "Python.h"
>
> becomes:
>
> #ifdef _DEBUG
>   #undef _DEBUG
>   #include "Python.h"
>   #define _DEBUG
> #else
>   #include "Python.h"
> #endif
>
> This "tricks" Python.h into thinking this is not a debug build, and thus
> is looks for python24.lib instead, which does exist.  This works, and
> since I'm not trying to debug Python, I don't care that I'm not linking
> the debug library.  But having to manually change SWIG's output each
> time I generate it is a real pain.  Is there either a way to change
> SWIG's output to this or does anyone have another idea for how to
> workaround this problem?  And no, renaming python24.lib to
> python24_d.lib does not work :) (they aren't binary compatible).
>
>  

Bob, does this trick still work? Probably it is best to modify the first
line to #if defined(_DEBUG) && defined(SWIG_PYTHON_DEBUG), so that a
user must also specify SWIG_PYTHON_DEBUG. Otherwise it won't be possible
to use the proper Python debug version, which I think can be compiled up
manually.

William

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[nitro-4]

Am 22.06.2009, 23:36 Uhr, schrieb William S Fulton  
<wsf@...>:

> Bob Marinier wrote:
>> Hi,
>>
>> I'm wrapping some code for Python on Windows using Visual Studio 2005
>> (although I think this will all be exactly the same in 6 and 2003).
>>
>> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
>> to be defined).  Something in Python.h, then, tells the linker it needs
>> python24_d.lib.  The problem is that the Windows installer for Python
>> does not include this file.  One possible workaround I found on the
>> Python mailing list is to change the SWIG output so that
>>
>> #include "Python.h"
>>
>> becomes:
>>
>> #ifdef _DEBUG
>>   #undef _DEBUG
>>   #include "Python.h"
>>   #define _DEBUG
>> #else
>>   #include "Python.h"
>> #endif
>>
>> This "tricks" Python.h into thinking this is not a debug build, and thus
>> is looks for python24.lib instead, which does exist.  This works, and
>> since I'm not trying to debug Python, I don't care that I'm not linking
>> the debug library.  But having to manually change SWIG's output each
>> time I generate it is a real pain.  Is there either a way to change
>> SWIG's output to this or does anyone have another idea for how to
>> workaround this problem?  And no, renaming python24.lib to
>> python24_d.lib does not work :) (they aren't binary compatible).

> Bob, does this trick still work? Probably it is best to modify the first
> line to #if defined(_DEBUG) && defined(SWIG_PYTHON_DEBUG), so that a
> user must also specify SWIG_PYTHON_DEBUG. Otherwise it won't be possible
> to use the proper Python debug version, which I think can be compiled up
> manually.

No, this trick does not work anymore with Python 2.6 and MSVC 2008. If you  
apply the trick, Visual C++ will complain that some header files have been  
compiled with  DEBUG defined and some without. The only thing I have found  
to make this work is to edit pyconfig.h and comment the #pragma (lib) and  
#define Py_DEBUG lines.
I have also raised the issue at the python bugtracker a year or two ago  
and they basically said "won't fix, if you want to use debug library,  
compile python in debug mode". This didn't make much sense to me as I  
wanted the python part to be release mode and my part to be debug mode,  
but the "won't fix" is how the discussion ended.

-Matthias

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[malat]

On Tue, Jun 23, 2009 at 1:53 PM, Nitro<nitro@...> wrote:

> Am 22.06.2009, 23:36 Uhr, schrieb William S Fulton
> <wsf@...>:
>
>> Bob Marinier wrote:
>>> Hi,
>>>
>>> I'm wrapping some code for Python on Windows using Visual Studio 2005
>>> (although I think this will all be exactly the same in 6 and 2003).
>>>
>>> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
>>> to be defined).  Something in Python.h, then, tells the linker it needs
>>> python24_d.lib.  The problem is that the Windows installer for Python
>>> does not include this file.  One possible workaround I found on the
>>> Python mailing list is to change the SWIG output so that
>>>
>>> #include "Python.h"
>>>
>>> becomes:
>>>
>>> #ifdef _DEBUG
>>>   #undef _DEBUG
>>>   #include "Python.h"
>>>   #define _DEBUG
>>> #else
>>>   #include "Python.h"
>>> #endif
>>>
>>> This "tricks" Python.h into thinking this is not a debug build, and thus
>>> is looks for python24.lib instead, which does exist.  This works, and
>>> since I'm not trying to debug Python, I don't care that I'm not linking
>>> the debug library.  But having to manually change SWIG's output each
>>> time I generate it is a real pain.  Is there either a way to change
>>> SWIG's output to this or does anyone have another idea for how to
>>> workaround this problem?  And no, renaming python24.lib to
>>> python24_d.lib does not work :) (they aren't binary compatible).
>
>> Bob, does this trick still work? Probably it is best to modify the first
>> line to #if defined(_DEBUG) && defined(SWIG_PYTHON_DEBUG), so that a
>> user must also specify SWIG_PYTHON_DEBUG. Otherwise it won't be possible
>> to use the proper Python debug version, which I think can be compiled up
>> manually.
>
> No, this trick does not work anymore with Python 2.6 and MSVC 2008. If you
> apply the trick, Visual C++ will complain that some header files have been
> compiled with  DEBUG defined and some without. The only thing I have found
> to make this work is to edit pyconfig.h and comment the #pragma (lib) and
> #define Py_DEBUG lines.
> I have also raised the issue at the python bugtracker a year or two ago
> and they basically said "won't fix, if you want to use debug library,
> compile python in debug mode". This didn't make much sense to me as I
> wanted the python part to be release mode and my part to be debug mode,
> but the "won't fix" is how the discussion ended.

I posted my solution a couple of months back, but here it is again (I
am using some cmake magic here to do the full path include trick).

Ref:
http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Wrapping/Python/Python.h.in?view=markup

HTH

--
Mathieu

------------------------------------------------------------------------------
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[malat]

On Wed, Jun 24, 2009 at 4:54 PM, Mathieu
Malaterre<mathieu.malaterre@...> wrote:

> On Tue, Jun 23, 2009 at 1:53 PM, Nitro<nitro@...> wrote:
>> Am 22.06.2009, 23:36 Uhr, schrieb William S Fulton
>> <wsf@...>:
>>
>>> Bob Marinier wrote:
>>>> Hi,
>>>>
>>>> I'm wrapping some code for Python on Windows using Visual Studio 2005
>>>> (although I think this will all be exactly the same in 6 and 2003).
>>>>
>>>> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
>>>> to be defined).  Something in Python.h, then, tells the linker it needs
>>>> python24_d.lib.  The problem is that the Windows installer for Python
>>>> does not include this file.  One possible workaround I found on the
>>>> Python mailing list is to change the SWIG output so that
>>>>
>>>> #include "Python.h"
>>>>
>>>> becomes:
>>>>
>>>> #ifdef _DEBUG
>>>>   #undef _DEBUG
>>>>   #include "Python.h"
>>>>   #define _DEBUG
>>>> #else
>>>>   #include "Python.h"
>>>> #endif
>>>>
>>>> This "tricks" Python.h into thinking this is not a debug build, and thus
>>>> is looks for python24.lib instead, which does exist.  This works, and
>>>> since I'm not trying to debug Python, I don't care that I'm not linking
>>>> the debug library.  But having to manually change SWIG's output each
>>>> time I generate it is a real pain.  Is there either a way to change
>>>> SWIG's output to this or does anyone have another idea for how to
>>>> workaround this problem?  And no, renaming python24.lib to
>>>> python24_d.lib does not work :) (they aren't binary compatible).
>>
>>> Bob, does this trick still work? Probably it is best to modify the first
>>> line to #if defined(_DEBUG) && defined(SWIG_PYTHON_DEBUG), so that a
>>> user must also specify SWIG_PYTHON_DEBUG. Otherwise it won't be possible
>>> to use the proper Python debug version, which I think can be compiled up
>>> manually.
>>
>> No, this trick does not work anymore with Python 2.6 and MSVC 2008. If you
>> apply the trick, Visual C++ will complain that some header files have been
>> compiled with  DEBUG defined and some without. The only thing I have found
>> to make this work is to edit pyconfig.h and comment the #pragma (lib) and
>> #define Py_DEBUG lines.
>> I have also raised the issue at the python bugtracker a year or two ago
>> and they basically said "won't fix, if you want to use debug library,
>> compile python in debug mode". This didn't make much sense to me as I
>> wanted the python part to be release mode and my part to be debug mode,
>> but the "won't fix" is how the discussion ended.
>
> I posted my solution a couple of months back, but here it is again (I
> am using some cmake magic here to do the full path include trick).
>
> Ref:
> http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Wrapping/Python/Python.h.in?view=markup

As a side note, when using a newer swig version, I think this is now
possible to include some custom header *just* before the swig #include
<Python.h> which make the trick a little easier (and does not require
cmake magic)


--
Mathieu

------------------------------------------------------------------------------
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Vallon, Justin-2]

I believe that the release python lib links with different (and incompatible) runtime libraries than your debug C++ code, and thus any workaround is looking for trouble (read: behavior undefined).  If I recall, for example, some structures were different between debug and release builds in the C++ header/lib (debug includes extra info), and that it is inconsistent to have one object/lib (python) link against the release support libraries while other objects (your code) compile/link against the debug support libraries.

I believe this is an issue for Python because it uses C++ (while Perl, for example, uses C and does not have debug/release incompatibility issues).

-Justin
-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre@...]
Sent: Wednesday, June 24, 2009 11:57 PM
To: Nitro
Cc: Bob Marinier; swig-user@...; William S Fulton
Subject: Re: [Swig-user] problems with python24_d.lib

On Wed, Jun 24, 2009 at 4:54 PM, Mathieu
Malaterre<mathieu.malaterre@...> wrote:

> On Tue, Jun 23, 2009 at 1:53 PM, Nitro<nitro@...> wrote:
>> Am 22.06.2009, 23:36 Uhr, schrieb William S Fulton
>> <wsf@...>:
>>
>>> Bob Marinier wrote:
>>>> Hi,
>>>>
>>>> I'm wrapping some code for Python on Windows using Visual Studio 2005
>>>> (although I think this will all be exactly the same in 6 and 2003).
>>>>
>>>> When I'm doing a debug build, the symbol _DEBUG is defined (and it needs
>>>> to be defined).  Something in Python.h, then, tells the linker it needs
>>>> python24_d.lib.  The problem is that the Windows installer for Python
>>>> does not include this file.  One possible workaround I found on the
>>>> Python mailing list is to change the SWIG output so that
>>>>
>>>> #include "Python.h"
>>>>
>>>> becomes:
>>>>
>>>> #ifdef _DEBUG
>>>>   #undef _DEBUG
>>>>   #include "Python.h"
>>>>   #define _DEBUG
>>>> #else
>>>>   #include "Python.h"
>>>> #endif
>>>>
>>>> This "tricks" Python.h into thinking this is not a debug build, and thus
>>>> is looks for python24.lib instead, which does exist.  This works, and
>>>> since I'm not trying to debug Python, I don't care that I'm not linking
>>>> the debug library.  But having to manually change SWIG's output each
>>>> time I generate it is a real pain.  Is there either a way to change
>>>> SWIG's output to this or does anyone have another idea for how to
>>>> workaround this problem?  And no, renaming python24.lib to
>>>> python24_d.lib does not work :) (they aren't binary compatible).
>>
>>> Bob, does this trick still work? Probably it is best to modify the first
>>> line to #if defined(_DEBUG) && defined(SWIG_PYTHON_DEBUG), so that a
>>> user must also specify SWIG_PYTHON_DEBUG. Otherwise it won't be possible
>>> to use the proper Python debug version, which I think can be compiled up
>>> manually.
>>
>> No, this trick does not work anymore with Python 2.6 and MSVC 2008. If you
>> apply the trick, Visual C++ will complain that some header files have been
>> compiled with  DEBUG defined and some without. The only thing I have found
>> to make this work is to edit pyconfig.h and comment the #pragma (lib) and
>> #define Py_DEBUG lines.
>> I have also raised the issue at the python bugtracker a year or two ago
>> and they basically said "won't fix, if you want to use debug library,
>> compile python in debug mode". This didn't make much sense to me as I
>> wanted the python part to be release mode and my part to be debug mode,
>> but the "won't fix" is how the discussion ended.
>
> I posted my solution a couple of months back, but here it is again (I
> am using some cmake magic here to do the full path include trick).
>
> Ref:
> http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Wrapping/Python/Python.h.in?view=markup

As a side note, when using a newer swig version, I think this is now
possible to include some custom header *just* before the swig #include
<Python.h> which make the trick a little easier (and does not require
cmake magic)


--
Mathieu

------------------------------------------------------------------------------
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

------------------------------------------------------------------------------
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user