From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#9960: Compiling Emacs trunk with MSVC Date: Fri, 11 Nov 2011 22:55:54 +0100 Message-ID: References: <83sjy5279e.fsf@gnu.org> <8339e2lsu7.fsf@gnu.org> <83zkgakdby.fsf@gnu.org> <4EB5320F.5090800@gmail.com> <83vcqyk8k3.fsf@gnu.org> <4EB540F4.7080106@gmail.com> <83r51mk62f.fsf@gnu.org> <86wrbeo7p5.fsf@googlemail.com> <83k47ejyyt.fsf@gnu.org> <86sjm2o559.fsf@googlemail.com> <86obwqo2hl.fsf@googlemail.com> <86ipmynwds.fsf@googlemail.com> <838vnujm3z.fsf@gnu.org> <83sjlzj25l.fsf@gnu.org> <8339dvgfpv.fsf@gnu.org> <83pqgyfnbf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00032556075e0d25d404b17c97f7 X-Trace: dough.gmane.org 1321048615 622 80.91.229.12 (11 Nov 2011 21:56:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2011 21:56:55 +0000 (UTC) Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 11 22:56:50 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ROz5e-0004SX-1I for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 22:56:50 +0100 Original-Received: from localhost ([::1]:60909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROz5c-0005mN-Qo for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 16:56:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROz5Y-0005m7-U5 for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 16:56:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROz5X-0005ze-Pm for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 16:56:44 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROz5X-0005za-OG for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 16:56:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ROz5p-0008Lp-KM for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 16:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 21:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9960 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9960-submit@debbugs.gnu.org id=B9960.132104860232071 (code B ref 9960); Fri, 11 Nov 2011 21:57:01 +0000 Original-Received: (at 9960) by debbugs.gnu.org; 11 Nov 2011 21:56:42 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROz5V-0008LD-Ld for submit@debbugs.gnu.org; Fri, 11 Nov 2011 16:56:42 -0500 Original-Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROz5T-0008L0-CI for 9960@debbugs.gnu.org; Fri, 11 Nov 2011 16:56:40 -0500 Original-Received: by bkbzv15 with SMTP id zv15so3518087bkb.3 for <9960@debbugs.gnu.org>; Fri, 11 Nov 2011 13:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fIVrTah7VwTfOtb/r9byf26Scwic4j9LUvepsKHlcCM=; b=siaPbqr7PS5MOD63imnjeKWJ5BADImyXEGHRTJz0A75DHrbV4wUY0d0gcwPZ4nq/2G HqCe6OnHnX1xPHlPDyOH/E3wjqy5J3v20ckay86+YW6Cd99/DOOnosVrAL85oE1Ba7Jm yjRBKD37B2t76pGlDa0sRa27ebBuhbkEkrSTo= Original-Received: by 10.204.29.8 with SMTP id o8mr9656639bkc.48.1321048575124; Fri, 11 Nov 2011 13:56:15 -0800 (PST) Original-Received: by 10.204.120.6 with HTTP; Fri, 11 Nov 2011 13:55:54 -0800 (PST) In-Reply-To: <83pqgyfnbf.fsf@gnu.org> X-Google-Sender-Auth: sbiVkmWAffBMSO5QcWuWW26-fxc X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 11 Nov 2011 16:57:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53821 Archived-At: --00032556075e0d25d404b17c97f7 Content-Type: text/plain; charset=ISO-8859-1 > > > 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 --00032556075e0d25d404b17c97f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I'l= l 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.<= br>
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 32bit= s executable.
Hence the reason for the 64bits manifest. So removi= ng addsection is not a priority
at all.
=A0
> 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 b= y MS
to answer that. =A0In 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. =A0So linking against libraries that are only
distributed with VS must be an option. =A0Even 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 :

<= div>=3D=3D=3D modified file 'nt/cmdproxy.c'
--- nt/cmdproxy.c =A0 =A0 =A0 2011-04-27 04:19:15 +0000
+++ = nt/cmdproxy.c =A0 =A0 =A0 2011-11-11 20:41:37 +0000
@@ -46,6 +46,= 8 @@
=A0#define stdout GetStdHandle (STD_OUTPUT_HANDLE)
=A0#define stderr GetStdHandle (STD_ERROR_HANDLE)

+#ifndef _MSC_VER
+
=A0int
=A0vfprintf (HANDLE hnd, const char * msg, va_list args)
=A0{
@@ -81,6 +83,7 @@

=A0 =A0return rc;
=
=A0}
+#endif /* _MSC_VER */

=A0void
=A0f= ail (const char * msg, ...)

This patch is ok= for both the static libc and the dynamic one.
Without it, link c= omplains that printf is redefined in the case of the static libc.
By the way, I don't know how the MingW libraries are organized, bu= t defining
printf and co to spare some functions when linking ... it doesn't = work with cl and
libc/msvcrt because other libc functions are use= d too : strncpy, strdup etc.
So it is not possible to avoid linki= ng against libc (?).

--
Fabrice
--00032556075e0d25d404b17c97f7--