bug#9960: Compiling Emacs trunk with MSVC

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Fri, 11 Nov 2011 22:55:54 +0100
> Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org
> 
> >  > 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 (?).

You will have to bear with me, as I cannot easily grok what you are
trying to explain.  E.g., what is "the static libc"?

To answer your question about MinGW, here are the default libraries
that the linker is instructed to scan when linking a program:

 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

Out of these, libgcc.a is a static library that comes with GCC,
libmingw32.a and libmingwex.a are static libraries specific to MinGW
(the former includes the startup modules like CRTglob, the latter math
functions and a few MinGW replacements for missing or buggy functions
from the MS runtime), libmoldname.a is a static library of stubs that
provide FOO where MS runtime only has _FOO (like _access, _dup2,
etc.), and all the rest are Windows dynamic libraries; MinGW just
supplies import libs for them.  I hope this answers your question
about the organization of the MinGW libraries.  IIUC, the above means
MinGW does not have any "static libc", so it must link against the
dynamic libraries that constitute the MS runtime.