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: Sat, 12 Nov 2011 15:34:56 +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> <83hb29fo0k.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001517588cfaef3dbd04b18a8bce X-Trace: dough.gmane.org 1321108560 28740 80.91.229.12 (12 Nov 2011 14:36:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2011 14:36:00 +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 Sat Nov 12 15:35:55 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 1RPEgQ-0004MB-Ui for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Nov 2011 15:35:54 +0100 Original-Received: from localhost ([::1]:58395 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPEgP-0007es-Vg for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Nov 2011 09:35:49 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPEgL-0007eS-JS for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 09:35:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPEgI-00028u-On for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 09:35:45 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPEgF-00028i-TB for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 09:35:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RPEgb-0006QM-W6 for bug-gnu-emacs@gnu.org; Sat, 12 Nov 2011 09:36:02 -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: Sat, 12 Nov 2011 14:36: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.132110854924674 (code B ref 9960); Sat, 12 Nov 2011 14:36:01 +0000 Original-Received: (at 9960) by debbugs.gnu.org; 12 Nov 2011 14:35:49 +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 1RPEgP-0006Pv-E4 for submit@debbugs.gnu.org; Sat, 12 Nov 2011 09:35:49 -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 1RPEgM-0006Pi-Gv for 9960@debbugs.gnu.org; Sat, 12 Nov 2011 09:35:48 -0500 Original-Received: by bkbzv15 with SMTP id zv15so4042153bkb.3 for <9960@debbugs.gnu.org>; Sat, 12 Nov 2011 06:35:18 -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=e/z7PSDWG6ei/ARQQ5bzd9nvSv8xR+UANVGJlzsra0g=; b=bPkEHlYxizdUQhzBPi7eDou/qsdgAQCfC1MnMQtuD3SKOnaV95KFUw+UaJLvcoKyeS KWzZLSWDNe78rD0C/G6bLgpGsX+8VOM/5S3Nswp6pGGd3Y4JV/Bh2MkZp+5eoMnn2br2 UQg0EBL7kUbVqtHBWkTx3P8wH78oKaX2+hAvY= Original-Received: by 10.204.7.144 with SMTP id d16mr12138806bkd.70.1321108518157; Sat, 12 Nov 2011 06:35:18 -0800 (PST) Original-Received: by 10.204.120.6 with HTTP; Sat, 12 Nov 2011 06:34:56 -0800 (PST) In-Reply-To: <83hb29fo0k.fsf@gnu.org> X-Google-Sender-Auth: p77j_a6It-KET7wlYA7jNN3h84E X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 12 Nov 2011 09:36: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:53832 Archived-At: --001517588cfaef3dbd04b18a8bce Content-Type: text/plain; charset=ISO-8859-1 > > > 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"? There are two MS C libraries you can link with : - libc is a static library, - msvcrt is a dll http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.100).aspx 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. > Ok, thanks for this detailed explanation. So it seems that MINGW compiled programs are linked with the MS msvcrt.dll ? But then, you would need to provide msvcrt.dll together with your binaries ? Anyway, in the case of cmdproxy, the source code states that : /* 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 --001517588cfaef3dbd04b18a8bce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> So, I have rebuilt emacs with the static libc. It is working t= oo,
> except for nt/cmdproxy that required :
>
> =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
> =A0fail (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. =A0By the way, I don't know how the MingW librari= es
> 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. =A0So 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. =A0E.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 t= hat in the event you compile your program in several modules, and each of t= hese modules need a C library, if you use msvcrt, then internal variables o= f 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 f= or functions like strtok for example).

Also, to complete what I wrote previously about install= ation and redistributables.=A0
It is perfectly possible to compil= e a foo.exe program and link it with the current release
of msvcr= t (say msvcrt100.dll) and pack this library in the very same directory=A0
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 anywh= ere else.

=A0
To answer your question about MinGW, here are the default libraries
that the linker is instructed to scan when linking a program:

=A0-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
=A0-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. =A0I hope this answers your question
about the organization of the MinGW libraries. =A0IIUC, the above means
MinGW does not have any "static libc", so it must link against th= e
dynamic libraries that constitute the MS runtime.

Ok, thanks for this detailed explanation.=A0
So = it seems that MINGW compiled programs are linked with the MS msvcrt.dll ?
But then, you would need to provide msvcrt.dll together with your = binaries ?


Anyway, in the case of cmdproxy, the sou= rce code states that :

/* We don't want t= o include stdio.h because we are already duplicating
=A0 =A0lots = of it here */
extern int _snprintf (char *buffer, size_t count, const char *format, = ...);

/******* =A0Mock C library routines =A0*****= ****************************/

/* These routines ar= e used primarily to minimize the executable size. =A0*/

I don't see exactly how to minimze executable size = except by not linking=A0
with any C library. It would be possible= to replace the other string functions
used in cmdproxy.c=A0by Wi= n32 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 fac= t that
they conflict when I link against the static libc.
(Not sure why they don't when linking with msvcrt, I bet it is bec= ause of an underscore again).

Greetings,

--
Fabrice
--001517588cfaef3dbd04b18a8bce--