Hi Doug, On 17/05/07, Doug Cook <[EMAIL PROTECTED]> wrote:
Bram is wise.
No objection here ;-).
Adding a nodefaultlib:msvcrt could potentially break things if you set USE_MSVCRT=1 to use the CRT DLL instead of statically linking the CRT. The problem is that you're linking a static-CRT version of Vim with DLL-CRT versions of ActiveState components. The problem is not with Vim's makefile.
Adding /nodefaultlib:msvcrt does not affect USE_MSVCRT=1, which will add the NON-default library msvcrt.lib explicitly. In fact, I think /nodefaultlib:msvcrt is really symmetrical with the current setting. We already have /nodefaultlib:libc, which disables the default static libc. Why should we allow default dynamic libc while disabling default static libc?
Generally, if you have lib conflicts, it means you've done something wrong. In this case, you have one OBJ that was compiled for use with the static CRT, and another OBJ that was compiled for use with the dynamically-linked CRT. Each of them tell the linker "you should probably link me with this particular CRT". Luckily, the linker is smart enough to only allow one CRT at a time.
Lib conflicts are something wrong, but not necessarily serious. It is a serious problem only if one does some foolish things like malloc in one CRT and free in another. Also, the linker does allow two CRTs at the same time, and which occurred to me, if I did not add /nodefaultlib:msvcrt. LibcMT will be linked, but the following five functions are imported from MSVCR71.dll: _fileno _chdir _fdopen _dup _putenv _stat _dup2
For a standalone program, statically linking with the CRT is generally the way to go, so Vim defaults to doing this. Using the CRT DLL saves about 150k in disk space, but the CRT DLL is 400-800k, depending on which version of Visual C++ you're using. The CRT is potentially already in memory in another process, so this may or may not save memory at runtime. For a program that interacts with other DLLs (such as loading Perl, Python, Ruby, etc. DLLs at runtime), the CRT DLL starts to make more sense. In addition to saving disk space (one CRT DLL instead of 150k of static CRT in each executable), you save memory (one CRT DLL loaded, and all modules share the same heap) and in some cases you avoid bugs (only one CRT so you don't have conflicting CRT settings like locale). However, you now have to redistribute the CRT with your product, and starting with VC 8.0, you have to get the CRT's manifest correctly embedded into your EXE and DLLs.
Another problem with CRT DLL is that different MSVC versions will make the resulting executable dependent on different CRT DLLs. Linking with MSVCRT.LIB in MSVC 7.1 results in the dependency on MSVCR71.DLL instead of MSVCRT.DLL. This is not something we like, I suppose. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
