RE: [boost] Why do we build debug variants of our compiled libraries?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, March 23, 2005 9:13 AM To: boost@lists.boost.org Subject: Re: [boost] Why do we build debug variants of our compiled libraries?
Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required.
There is one exception: if you're using VC++ or some other compiler
that
ships with multiple runtimes, then you *must* link against a Boost lib that's built against the same runtime as your application is using (probably a debug runtime during development). Of course on Linux (and probably most Unix variants) this is a non-issue.
John.
[Brian Braatz Writes:] thanks John- that is a good point I recall you CAN also accomplish rolling in a "release" version of the std runtime with debug build of an exe, but it is brittle and does not work in all cases for all types of projects- this solution requires you to very carefully tweak all the right compiler settings across all the libraries. In other words, just because you can doesn't mean you should :)
Brian Braatz wrote:
[Brian Braatz Writes:] thanks John- that is a good point
I recall you CAN also accomplish rolling in a "release" version of the std runtime with debug build of an exe, but it is brittle and does not work in all cases for all types of projects- this solution requires you to very carefully tweak all the right compiler settings across all the libraries.
In other words, just because you can doesn't mean you should :)
Borland always uses a release version of the STL and run-time libs. If you want debug versions, you have to build them yourself. Running on windows, we get auto-linked by default which gives us the debug boost libs for our debug builds, but I'd be quite happy with release builds, providing there weren't any #ifdef _DEBUG in header files going to screw up structure alignment and such (as can happen if you don't use the multi-threaded version of some libs etc) Russell
At least in the serialization library it can occur that the library calls back into the users code. Also there are lots of c style asserts. These can be helpful in debugging users code. Finally, the release libraries collapse inline code to the point its impossible to figure out how one got to where he did. Sometimes debug and release code is built with incompatible options. A users code built for debug might call a function that was inlined in the release version of the library and left out of line in the debug version of the library. If this happens, an application built for debug may fail to link with one built for release - even though they use the same headers. So there are case where the debug libraries are useful for things other than debugging the library itself. Robert Ramey
On Mar 23, 2005, at 1:19 PM, Robert Ramey wrote:
At least in the serialization library it can occur that the library calls back into the users code. Also there are lots of c style asserts. These can be helpful in debugging users code. Finally, the release libraries collapse inline code to the point its impossible to figure out how one got to where he did.
All great reasons to have the option to build debug libraries, but not reasons to build debug versions by default. Here's one reason not to build debug versions by default: they could give the user the impression that Boost is bulky and slow, because they're using code only meant for debugging the library itself or errors in the use of the library.
Sometimes debug and release code is built with incompatible options. A users code built for debug might call a function that was inlined in the release version of the library and left out of line in the debug version of the library. If this happens, an application built for debug may fail to link with one built for release - even though they use the same headers.
We know of one compiler where this does occur (Visual C++), but I believe this is the exception and not the rule.
So there are case where the debug libraries are useful for things other than debugging the library itself.
Agreed. Doug
participants (4)
-
Brian Braatz -
Doug Gregor -
Robert Ramey -
Russell Hind