[Boost-users] Re: Controlling selection of runtime libraries

From: Bob Kline (bkline_at_[hidden])
Date: 2004-03-21 20:47:39

Edward Diener wrote:
> Bob Kline wrote:
> 
>>We're using Boost's regex package in a Windows environment for a
>>server built with Microsoft Visual Studio 7.x.  We'd like to be able
>>to build our server with debugging symbols for our own code, but
>>still use the release versions of the Microsoft runtime DLLs (because
>>the debugging versions of the Microsoft runtime DLLs aren't
>>redistributable, so we can't legally install them on our production
>>server).
> 
> Why would you want to install the debug versions of a DLL on a production
> server ?

Edward:

Thanks for your reply.

Actually, the only part of the server program which we want debugging 
symbols for is our own code, which gets compiled and linked into the 
program's executable binary.  We'd prefer to have all DLLs (third-party 
and runtime) be release versions, but debugging versions of the 
third-party packages are OK, too, as long as they're not linked to the 
debug versions of the runtime libraries.  While we have found bugs in 
Microsoft's runtime libraries from time to time (as well as in the 
third-party packages we're using), most of the time when there's a bug 
it's in our own code (that's probably true for most systems; third-party 
libaries in widespread use get much more shakedown and eyeballs than the 
individual programs using them, and that's doubly true for the runtime 
libraries).  Having the same binaries running on all servers 
(production, testing, and development) makes it easier to eliminate 
spurious differences in behavior caused by software built differently 
for the different machines.  When a bug does come up, we're able to fire 
up the debugger and start looking for the problem without rebuilding a 
different version, which might introduce different behavior or even make 
the bug disappear.  We can even debug the production server (off-hours) 
remotely.  We know that on the less frequent occasions that the problem 
isn't in our own code, we'll have to build some of the other components 
with debugging symbols (or even dig into the vendor's source code for 
the runtime library using the version of the runtime that has debugging 
symbols).  Any setup will involve tradeoffs, but we think the choice 
we've made is reasonable, at least for our own application (we don't 
have to distribute binaries to customers for the server, so size of the 
image isn't really an issue).

Does that help?

Bob