Re: [Boost-users] [python] partially resolved: the never endingstoryof vc8/win32 linker settings desaster

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-08-14 03:33:45

Andrea Denzler <andrea <at> andreaplanet.com> writes:

> Sorry. Generally I have no problems linking (Debug executables) to Release
> libraries. 

Then you are lucky, or your executables are smaller than 2MB.

I have internal compiler/linker errors every day
(nice to see VS is built below drive F:), 
not only crashing Visual Studio 2005, but sometimes also forcing me to reboot. 
If only this mad behaviour was reproducible. 
It starts to remind me of gcc-3.0 on hpux-10.2 (2 alpha systems in unholy 
combination)

> For example in the linker options I specify icuuc.lib or
> icuucd.lib to link boost::regex to the ICU Debug or Release Library. Both
> cases works well in Debugging. 

How can you debug into the library, if the library has no debug symbols?

> So the idea to force the debug python libraries is a overkill.

I strongly disagree. It is the normal thing to do. 
If I debug, I debug and if I run release code I run release lib versions.
Also it is not about forcing anyone, but about the fact that it is
impossible due to the symbol incompatibility.

> Now, when using boost::python in _DEBUG then it is better to use python too
> in _DEBUG or it's standard release version? I think it's better to use the
> release version because else as you said you have to download and rebuild
> the python library only because I want boost in _DEBUG. 

This is what it is all about. Boost.Python tries to fix the broken
release scheme of Python and by this introduces silent breaks and 
endless headache with uninituitive behaviour. 

What is wrong with downloading python sources, clicking on a predefined
.sln file, pressing the key combination SHIFT-B, waiting 3 minutes,
opening the explorer and copyying the libs to the correct place?

> Of course the best would be to modify boost::python so that we can choose if
> to use python debug or release, 

This is excatly what I want.
I am looking forward to comments whether my solution idea of moving init calls 
to a header is OK or not.

> even better if we can choose this at link time like I do with other libraries.

Yes.

Markus