visual c++ - Is /nodefaultlib:msvcr100 the proper approach to handling msvcr100.dll vs msvcr100d.dll defaultlib issue -
for cross-platform software project builds on linux , windows have distinct ways handle third-party libraries. on linux build , link against versions distributed centos/rhel distribution, means link against release builds, whereas on windows maintain our own third-party library "packages" , on windows build 2 versions of every library - release version links msvcr100 , msvcp100 , debug version links msvcr100d , msvcp100d.
my question whether necessary build debug version of third-party dependencies on windows or can use /nodefaultlib:msvcr100 when building debug builds of our own software.
a follow question: can learn practices in regard. i've read msdn pages msvc runtime, there little there in terms of recommendations.
edit:
let me rephrase question more concisely. vs2010, problem using /nodefaultlib:msvcr100 link executable build /mdd when linking libraries compiled /md.
my motivation avoid have build both release , debug version of third party libraries use. want debug build run faster.
from document /md, /mt, /ld (use run-time library):
md: causes application use multithread- , dll-specific version of run-time library. defines _mt , _dll , causes compiler place library name msvcrt.lib .obj file.
applications compiled option statically linked msvcrt.lib. library provides layer of code allows linker resolve external references. actual working code contained in msvcr100.dll, must available @ run time applications linked msvcrt.lib
/mdd: defines _debug, _mt, , _dll , causes application use debug multithread- , dll-specific version of run-time library. causes compiler place library name msvcrtd.lib .obj file.
so there no documentation difference done generated code other _debug being defined.
you use debug build of crt debug app. contains lots of asserts catch mistakes in code. never ship debug build of project, release build. nor can you, license forbids shipping msvcr100d.dll. building project correctly automatically avoids dependency on debug version of crt.
the /nodefaultlib linker option intended allow linking program custom crt implementation. quite rare programmers care lot building small programs , standard crt isn't small.
some programmers use /nodefaultlib has hack around link problem. induced when link code built debug configuration settings code built release configuration settings. or link code has incompatible crt choices, /md vs /mt. can work, no guarantee, of course sweeps real problem under floor mat.
so no, not proper choice, fixing core problem should goal. ensure .obj , .lib files built same compiler options , won't have problem. if means have pester library owner proper build pester first, hack around when you've discovered don't want have dependency on .lib anymore don't yet have time find alternative.
Comments
Post a Comment