[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9960: Compiling Emacs trunk with MSVC

From: Fabrice Popineau
Subject: bug#9960: Compiling Emacs trunk with MSVC
Date: Sat, 12 Nov 2011 15:34:56 +0100

> 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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]