>>but nt.mak contins line >> >>CFLAG= /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo >>-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 >>-D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM >>/Fdout32 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 >> >> >> >>The first option is /MD - Multithreaded DLL code generation >> >>But for static library option should be /MT Multithreaded code >>generation > > > Not really, IMHO. Note that /MD or /MT is just about whether you > want your (static) library to be used with the static C library > or with the DLL.
One can actually argue that originator might have a viable point! Well, I [also] disagree with formulation, /MD being *wrong*, but one can argue that /MT is simply *more versatile*! Let's just take a level below and figure out what *exactly* /MD vs. /MT means... At the upper level /MD means "define _DLL and _MT at compile time and link with MSVCRT at link time," right? At the object module level it effectively means "adhere to MT-safe API, prepend CRT functions with __imp__ prefix and tag object module with -defaultlib:MSVCRT." It should be explicitly noted that _DLL macro is effectively responsible for __imp__ prefix. Now what's the deal with /MT? It means "define _MT at compile time and link with LIBCMT at link time," right? At the object module level it effectively means "adhere to MT-safe API, call CRT functions by *undecorated* name and tag the object module with -defaultlib:LIBCMT." What happens if you try to mix object modules compiled with /MT [from application] and with /MD [from library]? Would it pull in MSVCRT to resolve __imp__ references from library and LIBCMT by means of of -defaultlib from application objects? Appears so... Would it have side effects? Yes, it would... Is there "right thing" to do? Hmmm.... What happens if you try to link undecorated symbol, one without __imp__ prefix, against MSVCRT? It's not a problem! Linker will transparently pull in a small stub for every CRT function you call, which would relay say _printf to __imp__printf! Would it work other way around? No! So wouldn't it be appropriate to say that it's actually more versatile option to generate static lib with /MT, i.e. without __imp__-prefixed symbols, and allow application developer decide which library, MSVCRT or LIBCMT, he wants to link with? Yes. But there is a pitfall! Application developer may no longer depend on /MT or /MD at link time, but instead link with /LINK /NODEFAULTLIB[:LIBCMT] and *then* pick either LIBCMT.LIB or MSVCRT.LIB, whichever appropriate. Well, only MSVCRT developer would actually have to bother... In other words. One can actually argue that it's more appropriate to generate static library with /MT instead of /MD, but given that MSVCRT application developers adhere to /LINK /NODEFAULTLIB:LIBCMT MSVCRT.LIB upon target application link. Further opinions? BTW, is there a way to prevent compiler from tagging object module with *any* -defaultlib? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
