From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#9960: Compiling Emacs trunk with MSVC Date: Sat, 12 Nov 2011 15:50:35 +0200 Message-ID: <83hb29fo0k.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321106032 13988 80.91.229.12 (12 Nov 2011 13:53:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2011 13:53:52 +0000 (UTC) Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org To: Fabrice Popineau Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 12 14:53:47 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 1RPE1j-0003V5-AW for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Nov 2011 14:53:47 +0100 Original-Received: from localhost ([::1]:53911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPE1i-00086R-Px for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Nov 2011 08:53:46 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:37491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPE1f-00085x-S4 for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 08:53:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPE1c-0004FF-Ua for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 08:53:43 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPE1c-0004FB-Ro for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 08:53:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RPE1y-0005Tj-Rq for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 08:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Nov 2011 13:54:02 +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.132110603321017 (code B ref 9960); Sat, 12 Nov 2011 13:54:02 +0000 Original-Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 13:53:53 +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 1RPE1p-0005Sv-0x for submit@debbugs.gnu.org; Sat, 12 Nov 2011 08:53:53 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RPE1m-0005Si-O2 for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 08:53:52 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUJ00J00VCY1M00@a-mtaout20.012.net.il> for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 15:52:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUJ00HP3VVJQMS0@a-mtaout20.012.net.il>; Sat, 12 Nov 2011 15:52:32 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 12 Nov 2011 08:54:02 -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:53829 Archived-At: > From: Fabrice Popineau > Date: Fri, 11 Nov 2011 22:55:54 +0100 > Cc: cschol2112@googlemail.com, 9960@debbugs.gnu.org > > > > 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 (?). 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"? 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.