> > > I'll try to remove the use of addsection if possible. Well, if someone > has > > a good reason for which it is not possible, let me know. > > Most people build Emacs using MinGW, where editbin is not available. > > But we could tweak gmake.defs and nmake.defs such that MSVC builds do > use editbin. Ok. Good point. At first, when I tried the 64bits build, the executable wouldn't run. I was afraid that it was because of the addsection tweak. Eventually, it turned out that it was the emacs.manifest file that specified the .exe as a 32bits executable. Hence the reason for the 64bits manifest. So removing addsection is not a priority at all. > > Being able to link against libc or msvcrt is confusing. > > Wouldn't it be better if only MSVCRT was supported ? > > Does the build work with the static libc ? > > Sorry, I don't know enough about the various libraries provided by MS > to answer that. In general, we must support a build against libraries > that are part of the OS, we cannot rely on users having the SDK or the > Studio installation. So linking against libraries that are only > distributed with VS must be an option. Even using vcredist packages > as a prerequisite would be a nuisance. > Even better point. MSVCRT.dll is provided with the OS and some parts of it are linked against this dll. However, Visual Studio provides msvcrt80.dll, msvcrt90.dll, msvcrt100.dll (one for each new release of VS) and they need to be redistributed with the program. It makes sense if you are building an installer (it is even easy). So, I have rebuilt emacs with the static libc. It is working too, except for nt/cmdproxy that required : === modified file 'nt/cmdproxy.c' --- nt/cmdproxy.c 2011-04-27 04:19:15 +0000 +++ nt/cmdproxy.c 2011-11-11 20:41:37 +0000 @@ -46,6 +46,8 @@ #define stdout GetStdHandle (STD_OUTPUT_HANDLE) #define stderr GetStdHandle (STD_ERROR_HANDLE) +#ifndef _MSC_VER + int vfprintf (HANDLE hnd, const char * msg, va_list args) { @@ -81,6 +83,7 @@ return rc; } +#endif /* _MSC_VER */ void fail (const char * msg, ...) This patch is ok for both the static libc and the dynamic one. Without it, link complains that printf is redefined in the case of the static libc. By the way, I don't know how the MingW libraries are organized, but defining printf and co to spare some functions when linking ... it doesn't work with cl and libc/msvcrt because other libc functions are used too : strncpy, strdup etc. So it is not possible to avoid linking against libc (?). -- Fabrice