bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Fri, 11 Nov 2011 22:55:54 +0100

> 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

reply via email to

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