Hello everyone
I'm creating a directX wrapper library (.lib), but im not sure how to configure it to be usable when the library user debugs his program
i made 1 copy of the library which is the release version, code generation is multi-threaded, and this library includes (depends on) another library (havok physics), so my library have included havok's multi-threaded release
now i made a program that uses this library, (i want to use both realse and debug of this app), so my release configurations are: code generation is multi-threaded, included my main library (release, the only copy) and havok library (multi-thread release version), this works just fine
but when it comes to the debug part, i dont know how should i configure it as im getting a bunch of errors, i need to include the release version of my library (because it's the only copy) and the release version of havok (so it works with my lib), if i set the code generation to multi-threaded debug, i get some mismatch errors, and if i set it to multi-threaded, i get another set of errors
so someone mind tell me what should i do? are the main library's configurations wrong? if not, how should this application's debug configurations be?
thanks in advance
-Hassan
library configurations
You'll have to give more info as to what your errors are.
IIRC, the code generation option you are mentioning has 4 different settings (dependent upon version of VS I believe), and the trick is to be sure everything is built with the same setting.
IIRC, the code generation option you are mentioning has 4 different settings (dependent upon version of VS I believe), and the trick is to be sure everything is built with the same setting.
Author
Quote:Original post by Drakonite
the trick is to be sure everything is built with the same setting.
Well yes, this worked with the release mode, but how can i build the library in release mode to suit both debug and release modes for the user application?
In general, you really want to have both a debug and release build of the library and link to the correct one. Mixing crt libraries is not a good thing.
However...
It's been a while since I've dealt with this, but IIRC you can link your library with /MT (multi-threaded static) and your debug executable with /MTd (debug multi-threaded static) and work correctly as long as you are careful to never mix the two memory environments. For example, you cannot allocate inside the library and have the main executable free it.
This may not be supported in later versions of Visual Studio, and it's never been recommended, however IIRC "it works".
But really... you should compile both a release and debug version of your library. You'll save yourself tons of headaches and chances are you'll be wanting some extra debug info from debug builds anyways. If you are worried about the performance differences... Don't. Your debug builds are going to be slower either way, and the debug info from the libraries will be crucial to fixing many bugs. If it gets to be that much of a problem, you can always enable optimization for the debug build of your library.
However...
It's been a while since I've dealt with this, but IIRC you can link your library with /MT (multi-threaded static) and your debug executable with /MTd (debug multi-threaded static) and work correctly as long as you are careful to never mix the two memory environments. For example, you cannot allocate inside the library and have the main executable free it.
This may not be supported in later versions of Visual Studio, and it's never been recommended, however IIRC "it works".
But really... you should compile both a release and debug version of your library. You'll save yourself tons of headaches and chances are you'll be wanting some extra debug info from debug builds anyways. If you are worried about the performance differences... Don't. Your debug builds are going to be slower either way, and the debug info from the libraries will be crucial to fixing many bugs. If it gets to be that much of a problem, you can always enable optimization for the debug build of your library.
Author
Quote:Original post by Drakonite
In general, you really want to have both a debug and release build of the library and link to the correct one. Mixing crt libraries is not a good thing.
Alright then, i'll just stick with having 2 libraries (release-debug)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement