Controlling selection of runtime libraries
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). The problem is, when we compile our own code for debugging (with -Zi and -D_DEBUG), the Boost headers detect this and do their behind-the-curtain magic to point to a version of the regex package which is linked to the debugging versions of the runtime libraries (msvcr71d and msvcp71d). We've tried using the BOOST_REGEX_NO_LIB trick, specifying the version of the regex library to which we want to link (boost_regex_vc7_mdi.lib) but this doesn't work, because although it compiles fine, the linker chokes complaining about the inability to find a bunch of severely mangled names. What's the *real* trick for using the version of the library we want? Do we need to hack the distributed makefile each time we upgrade regex? (Or worse, shuffle libraries around by renaming them?) Thanks. Bob Kline
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 ? If you are just testing your version on your own server, rather than distributing it to clients, I am sure MS wouldn't mind you installing the debug versions of their runtime DLLs on your own server for testing purposes. If you are distributing your code to clients, surely it must be right to be distributing the release and not the debug version to others. I am not the maintainer of Regex, John Maddock is, but the DLL is built to match up the debug version of the DLL with the debug version of the RTL and the release version of the DLL with the release version of the RTL. This seems completely normal to me while what you are asking seems very odd. I think you need to hack the source for your own use in order to match up a debug version with a release RTL.
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
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). The problem is, when we compile our own code for debugging (with -Zi and -D_DEBUG), the Boost headers detect this and do their behind-the-curtain magic to point to a version of the regex package which is linked to the debugging versions of the runtime libraries (msvcr71d and msvcp71d). We've tried using the BOOST_REGEX_NO_LIB trick, specifying the version of the regex library to which we want to link (boost_regex_vc7_mdi.lib) but this doesn't work, because although it compiles fine, the linker chokes complaining about the inability to find a bunch of severely mangled names.
Hmm, the Microsoft's docs specify that _DEBUG is "Defined when compiling with /LDd, /MDd, /MLd, and /MTd.", that isn't the case here, so it shouldn't be defined. However I've just checked, and the IDE does seem to want to set it when building in "debug" mode irrespective of which runtime you're actually using. If you're building from a makefile though the best idea would be to not define this symbol. Alternatively build in release mode with but with debug symbols on. If you build with BOOST_REGEX_NO_LIB defined then you will get undefined externals unless you manually specify which library to link against. BTW, I've just checked with Microsoft's own headers, and they also use _DEBUG to determine which runtime to link against, in the same manner that regex does - see for example use_ansi.h or comdef.h. John.
What's the *real* trick for using the version of the library we want? Do we need to hack the distributed makefile each time we upgrade regex? (Or worse, shuffle libraries around by renaming them?)
Thanks.
Bob Kline
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
John Maddock wrote:
If you're building from a makefile though the best idea would be to not define this symbol [_NDEBUG].
Thanks, that solved the problem.
If you build with BOOST_REGEX_NO_LIB defined then you will get undefined externals unless you manually specify which library to link against.
We tried specifying the library (boost_regex_vc7_mdi.lib) we wanted, but that didn't work, as it seems that the names of the symbols exported by the Boost regex library were not the same as they would have been for boost_regex_vc7_mdid.lib (unless we were doing something else wrong). But that doesn't matter, since your first suggestion above worked perfectly. Thanks again! Bob PS: By the way, kudos is in order. In all the decades I've been in this business, your regex package is the only third-party library I've used in a production system in which I have never found a bug. Cheers!
participants (3)
-
Bob Kline -
Edward Diener -
John Maddock