GNU bug report logs - #9960
Compiling Emacs trunk with MSVC

Previous Next

Full log

View this message in rfc822 format

From: Fabrice Popineau <fabrice.popineau <at> supelec.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cschol2112 <at> googlemail.com, 9960 <at> debbugs.gnu.org
Subject: bug#9960: Compiling Emacs trunk with MSVC
Date: Fri, 11 Nov 2011 22:55:54 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.