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#18302: MSYS2 build issues Date: Fri, 22 Aug 2014 09:30:19 +0300 Message-ID: <83egw9aves.fsf@gnu.org> References: <53F67389.8020501@alice.it> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1408689091 29174 80.91.229.3 (22 Aug 2014 06:31:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 06:31:31 +0000 (UTC) Cc: 18302@debbugs.gnu.org To: Angelo Graziosi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 22 08:31:25 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKiNe-0002Ul-LJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 08:31:22 +0200 Original-Received: from localhost ([::1]:35325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiNe-0003I8-61 for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 02:31:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiNV-0003H9-7k for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:31:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKiNK-00083S-HZ for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:31:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKiNK-00083O-DL for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKiNJ-0006AQ-RX for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 02:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Aug 2014 06:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18302 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18302-submit@debbugs.gnu.org id=B18302.140868903223665 (code B ref 18302); Fri, 22 Aug 2014 06:31:01 +0000 Original-Received: (at 18302) by debbugs.gnu.org; 22 Aug 2014 06:30:32 +0000 Original-Received: from localhost ([127.0.0.1]:49259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKiMp-00069c-0G for submit@debbugs.gnu.org; Fri, 22 Aug 2014 02:30:31 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:60012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKiMj-00069L-OW for 18302@debbugs.gnu.org; Fri, 22 Aug 2014 02:30:28 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NAP0040032NCD00@mtaout27.012.net.il> for 18302@debbugs.gnu.org; Fri, 22 Aug 2014 09:25:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAP00J2N35TSE90@mtaout27.012.net.il>; Fri, 22 Aug 2014 09:25:05 +0300 (IDT) In-reply-to: <53F67389.8020501@alice.it> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:92588 Archived-At: > Date: Fri, 22 Aug 2014 00:32:41 +0200 > From: Angelo Graziosi > > I do MSYS2-MinGW64 Emacs trunk builds with the simple steps: > > ./autogen.sh > > ./configure --prefix=/Emacs.app --with-wide-int > --build=x86_64-w64-mingw32 --without-imagemagick > 'CFLAGS=-I/mingw64/include/noX -Ofast -g0 -pipe' LDFLAGS=-pipe > > make... > > > The build needs the > > CFLAGS=-I/mingw64/include/noX > > definition because of the manner how MSYS2 work. It puts all the stuffs > depending on msys2*dll (the equivalent of cygwin1.dll) under /usr. > Instead the MinGW34 and MinGW64 applications are under /mingw32 and > /mingw64 respectively. Usually, to work with MinGW64 applications, one > needs to start the shell-console with mingw64_shell.bat batch file > (msys2_shell.bat or mingw32_shell.bat to work with MSYS2 or MinGW32 apps). Sorry, I don't understand what does this have to do with the issue at hand. You are talking about how MSYS2 maps the Posix-like /mingw32 and /mingw64 trees into Windows filesystems. Fine; but why does this matter in the context of this discussion? ISTM that if you want to be able to produce both MinGW32 and MinGW64 programs on the same machine, you need 2 separate hierarchies anyway, one for the 32-bit and the other for 64-bit programs. IOW, just copy the /usr/include tree into each of the mingwXX parents, and each respective compiler will find them automatically, because it always searches for ../include relative to its binary (you can see that with "gcc -v"). If that doesn't work, then set C_INCLUDE_PATH in the environment to point to the right include directory in each case. Without having this set up correctly, your development environment is subtly broken. And if MSYS2 somehow makes this hard or impossible, then it's an MSYS2 bug that should be fixed ASAP. > So, it is in the "nature" of MSYS2 that it puts things in non-standard > directory for MinGW32/64 apps. Probably one can change Emacs configure > to avoid these issue but I wonder, given the simple workaround shown > above, if this is worth the effort. As I explained in this discussion, this has nothing to do with Emacs. No, this is a basic compiler configuration issue: the headers should be in a place where the compiler can find them, period. No additional "-I" switches should be needed to allow the compiler to find the headers (and the library files) of an installed library/package. > Instead, it would interesting, to understand why removing the configure > option, "--without-imagemagick", with the MinGW64 ImageMagick package > installed, configure enables imagemagick support but the build fails > with a linker error.. but this is matter for another thread.. I think. The Windows build currently doesn't support ImageMagick. That's why you see those failures. Patches are welcome to add ImageMagick support in the same way we support other image libraries on Windows: i.e. via dynamic load at run time if the library exists and when it is first used. See image.c for the details.