> 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 (?).
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.
/* 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