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

From: Andrea Denzler (andrea_at_[hidden])
Date: 2008-08-14 09:18:47

Good to know that I am lucky with the compiler/linker (exe's over 2 MB).
It's always a bad experience to get internal compiler/linker errors. I can
accept a bug in a Office application but not in the compiler.

When I debug my code I want to find my bugs, so I am not always interested
in debugging other libraries, especially if they are huge and complex. If I
use the library release version of course I don't have any debug info on
that library but I have my code (and other libraries) in debug.
Also a library build in debug mode will have a different behavior than in
release mode. Maybe a hard to discover bug in my code is present only when
using the library in release mode due to different compiler optimizations.
At last a library in debug build is slower, sometimes much slower causing an
unacceptable overhead when testing heavy computation tasks.
So I definitively want always choose to use the debug or release version
when I am debugging my application.

I don't think there is a incompatibility when using libraries in release
build and your application in debug. Building in _DEBUG has three effects:
1) adding symbols: how this can create an incompatibility is unknown to me.
2) different compiler settings: internal optimizations also don't create
incompatibilities. Only the boundaries between the library and your source
code is affected, see next point.
3) different library behaviors: if the library use for example different
data structures when building in debug/release (i.e. adding extra members to
classes for debug info) and those structures are handled by your source code
too then your application will likely crash. But this is a library bug not a
VS bug. If the library use different structures this should be uniquely
identified using global symbols like Py_DEBUG so that the headers define
correctly the internal structures of the library, the used function calls,
the correct byte alignment, etc.

Sure, if VS is full of bugs and the workaround for you is to use all
libraries in _DEBUG then let's go on with this, but without forcing it to
everyone. Developers should be able to choose if they can use python.lib in
release or debug when compiling the application in _DEBUG. Which one is the
default option is not that important.

One point is that you had troubles using python in debug build, and this
should definitively be fixed in the boost::python. And probably you are one
of the few trying to do this else whoever use python is unable to build the
application in debug mode. But sometimes we are one of the few, like when I
wanted to use boost::regex and Unicode ICU, but boost 1.35 was unable to do
a complete build (already fixed in the current svn code). 

Andrea

-----Messaggio originale-----
Da: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] Per conto di Markus Werle
Inviato: giovedì 14 agosto 2008 9.34
A: boost-users_at_[hidden]
Oggetto: Re: [Boost-users][python] partially resolved: the never
endingstoryof vc8/win32 linker settings desaster

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

_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users