bug#9960: Compiling Emacs trunk with MSVC

[Fabrice Popineau <fabrice.popineau@supelec.fr>]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

>
> > 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"?


There are two MS C libraries you can link with :
- libc is a static library,
- msvcrt is a dll

http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.100).aspx

The main difference between both is that in the event you compile your
program in several modules, and each of these modules need a C library, if
you use msvcrt, then internal variables of the C library are shared amond
the modules, whereas each module gets its own C library internal state if
you use the static libc. (May be relevant for functions like strtok for
example).

Also, to complete what I wrote previously about installation and
redistributables.
It is perfectly possible to compile a foo.exe program and link it with the
current release
of msvcrt (say msvcrt100.dll) and pack this library in the very same
directory
foo.exe is located. You can zip them together and there is nothing to
install.
Your foo.exe program will be dynamically linked with the dll that are
located
in the same directory, before looking anywhere else.



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.
>

Ok, thanks for this detailed explanation.
So it seems that MINGW compiled programs are linked with the MS msvcrt.dll ?
But then, you would need to provide msvcrt.dll together with your binaries ?


Anyway, in the case of cmdproxy, the source code states that :

/* We don't want to include stdio.h because we are already duplicating
   lots of it here */
extern int _snprintf (char *buffer, size_t count, const char *format, ...);

/*******  Mock C library routines  *********************************/

/* These routines are used primarily to minimize the executable size.  */

I don't see exactly how to minimze executable size except by not linking
with any C library. It would be possible to replace the other string
functions
used in cmdproxy.c by Win32 functions and remove the C library from the
needed resources.
But that is not currently what's done.
So all in all, it is as easy to use the C library printf functions,
especially given the fact that
they conflict when I link against the static libc.
(Not sure why they don't when linking with msvcrt, I bet it is because of
an underscore again).

Greetings,

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 5697 bytes --]