please include python26_d.lib in the installer

[Compie]

I get this linker error
LINK : fatal error LNK1104: cannot open file 'python26_d.lib'
when I build the debug version of my Visual Studio project.

This is caused by the following lines in the file c:\Python26\include
\pyconfig.h
# ifdef _DEBUG
# pragma comment(lib,"python26_d.lib")
# else
# pragma comment(lib,"python26.lib")
# endif /* _DEBUG */

The file python26_d.lib is not installed by the Python installer on
Windows.

So please:
1. Provide python26_d.lib in the installer.
or
2. Remove this automatic "pragma comment lib" from pyconfig.h, since I
can't disable it from the outside (as far as I know).

Please note: I want to build my own code in Debug mode for debugging.
I don't want to build or use the debug version of Python. I also can't
#undef _DEBUG, since the file that includes pyconfig.h (via Python.h)
is generated by SWIG. Also I prefer not to change pyconfig.h myself,
since my code needs to compile on a lot of different machines.

 

[Carl Banks]

I get this linker error
LINK : fatal error LNK1104: cannot open file 'python26_d.lib'
when I build the debug version of my Visual Studio project.

This is caused by the following lines in the file c:\Python26\include
\pyconfig.h
#                       ifdef _DEBUG
#                               pragma comment(lib,"python26_d.lib")
#                       else
#                               pragma comment(lib,"python26.lib")
#                       endif /* _DEBUG */

The file python26_d.lib is not installed by the Python installer on
Windows.

So please:
1. Provide python26_d.lib in the installer.
or
2. Remove this automatic "pragma comment lib" from pyconfig.h, since I
can't disable it from the outside (as far as I know).

Please note: I want to build my own code in Debug mode for debugging.
I don't want to build or use the debug version of Python. I also can't
#undef _DEBUG, since the file that includes pyconfig.h (via Python.h)
is generated by SWIG. Also I prefer not to change pyconfig.h myself,
since my code needs to compile on a lot of different machines.

python26_d.dll *is* the debugging version of Python.

As a workaround to the situation, try to copy the file python26.dll to
python26_d.dll. (I'm not sure this will work; you say you are
building a SWIG library in debug mode, and it's possible that SWIG
will try to use features of the Python debugging version. If that's
the case, you'll have no choice but to use the debugging version of
Python.)

OTOH, it's possible that SWIG and Python just happen to use the same
macro to indicate debugging mode. So I think you raise a valid point
that this can be problematic. Perhaps something like _Py_DEBUG should
be used instead.


Carl Banks

 

[Mark Hammond]

Please note: I want to build my own code in Debug mode for debugging.

I don't want to build or use the debug version of Python. I also can't

Python does this on purpose so you don't accidentally mix different
versions of the C runtime library. This would happen ff you defined
DEBUG in your code but use Python built without DEBUG - Python using a
different name for its lib prevents this.

Note that just shipping the _d.lib wouldn't help - you would need the
_d.dll itself, plus *all* extension modules you use - *all* .pyd/.dll
etc files have the trailing _d, and a debug version of Python refuses to
load the release versions without the _d.

I'd recommend leaving DEBUG etc disbled, but enable debug information
and disable optimizations while debugging.

Cheers,

Mark

 

[Johan Compen]

Python does this on purpose so you don't accidentally mix different versions
of the C runtime library.  This would happen ff you defined DEBUG in your
code but use Python built without DEBUG - Python using a different name for
its lib prevents this.

Note that just shipping the _d.lib wouldn't help - you would need the _d.dll
itself, plus *all* extension modules you use - *all* .pyd/.dll etc files
have the trailing _d, and a debug version of Python refuses to load the
release versions without the _d.

I'd recommend leaving DEBUG etc disbled, but enable debug information and
disable optimizations while debugging.

If Python doesn't include the _d.lib file, then why does the header
file reference it? I would prefer manual control over which lib file
to use. (And I don't want to disable _DEBUG for other reasons).

Could the header file be changed so it alwas uses the release lib? In
most cases it's actually ok to mix different versions of the CRT in
one application. See the following blog post about this issue:

http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html

The goal is to use one runtime library throughout your entire application.

That is nearly impossible since you typically don't have control of
which runtime library other libraries use.

It turns out is is OK to mix runtime libraries *except* in certain
cases. A well written library should avoid these cases and then it
doesn't matter if the runtime libraries match. Libraries that cannot
avoid these cases should ship with 4 versions of their libraries that
match the 4 versions of the runtime libraries.


P.S. If pyconfig.h really wanted to use the correct CRT, then it would
need to reference different lib files for both VS2005 and 2008.

Johan.

 

[Compie]

OTOH, it's possible that SWIG and Python just happen to use the same
macro to indicate debugging mode.  So I think you raise a valid point
that this can be problematic.  Perhaps something like _Py_DEBUG should
be used instead.

This would be a good solution IMHO. I'm not the only one facing this
problem. The internet is full of people looking for this file...
http://www.google.com/search?q=python25_d.lib+error+cannot

_DEBUG is automatically defined by Visual Studio when you build the
Debug version of a project.
http://msdn.microsoft.com/en-us/library/0b98s6w8.aspx

So I'm proposing: please use _PYTHON_DEBUG for this purpose. Would
this cause any problems?

Johan.

 

[Carl Banks]

This would be a good solution IMHO. I'm not the only one facing this
problem. The internet is full of people looking for this file...http://www.google.com/search?q=python25_d.lib+error+cannot

_DEBUG is automatically defined by Visual Studio when you build the
Debug version of a project.http://msdn.microsoft.com/en-us/library/0b98s6w8.aspx

So I'm proposing: please use _PYTHON_DEBUG for this purpose. Would
this cause any problems?

Go to bugs.python.org and file a bug report with the conflict it is
causing you. (Well, first, make sure no one else has reported it.) I
advise you to stress the downfalls of the current approach in a
professional, respectful manner. You have been coming off as slightly
whiny in this thread, and that'll hurt your chances of getting such a
change approved. In particular, don't ask for anything, or ask why it
was implemented that way; just report the issue and suggest a fix.

I suspect they used _DEBUG deliberately. I disagree with that: a
generic symbol like _DEBUG should be avoided in general, and should
really be avoided when it entails a change in interface.


Carl Banks

 

[Compie]

Go to bugs.python.org and file a bug report with the conflict it is
causing you.  (Well, first, make sure no one else has reported it.)  I
advise you to stress the downfalls of the current approach in a
professional, respectful manner.  You have been coming off as slightly
whiny in this thread, and that'll hurt your chances of getting such a
change approved.  In particular, don't ask for anything, or ask why it
was implemented that way; just report the issue and suggest a fix.

I suspect they used _DEBUG deliberately.  I disagree with that: a
generic symbol like _DEBUG should be avoided in general, and should
really be avoided when it entails a change in interface.

Carl Banks

Yes you are right, whining here won't help, I will file a bug report.

But I really needed the discussion here before I could do that. I
didn't know all the pros and cons of the current approach.
I was just reporting a problem that I (and many others) have with
pyconfig.h and Debug mode. But I do recognize that my current approach
(how I reported this problem) is not the most effective one. Thanks
for the tip.

Johan.