From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: windows build failure Date: Fri, 20 Sep 2013 20:40:34 +0300 Message-ID: <8338ozl7cd.fsf@gnu.org> References: <83wqmeocl5.fsf@gnu.org> <83ioxynvpb.fsf@gnu.org> <87zjrae0q7.fsf@gmail.com> <83eh8mnu8h.fsf@gnu.org> <87ob7qdzxj.fsf@gmail.com> <83a9janq2l.fsf@gnu.org> <87bo3oew5i.fsf@gmail.com> <83wqmclwja.fsf@gnu.org> <8761twemxb.fsf@gmail.com> <83txhglke0.fsf@gnu.org> <871u4keezm.fsf@gmail.com> <83pps4kl3s.fsf@gnu.org> <87vc1v4lld.fsf@gmail.com> <834n9fle10.fsf@gnu.org> <87k3ib4fl7.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1379698849 1001 80.91.229.3 (20 Sep 2013 17:40:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Sep 2013 17:40:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Sean Sieger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 20 19:40:52 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VN4hG-0002pG-6x for ged-emacs-devel@m.gmane.org; Fri, 20 Sep 2013 19:40:50 +0200 Original-Received: from localhost ([::1]:57172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VN4hF-0002a7-JR for ged-emacs-devel@m.gmane.org; Fri, 20 Sep 2013 13:40:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VN4h5-0002Zh-H1 for emacs-devel@gnu.org; Fri, 20 Sep 2013 13:40:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VN4gx-0004Ug-Bq for emacs-devel@gnu.org; Fri, 20 Sep 2013 13:40:39 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VN4gx-0004UG-3R for emacs-devel@gnu.org; Fri, 20 Sep 2013 13:40:31 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MTF00100QCQB200@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 20 Sep 2013 20:40:29 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MTF000VBQFGY790@a-mtaout22.012.net.il>; Fri, 20 Sep 2013 20:40:29 +0300 (IDT) In-reply-to: <87k3ib4fl7.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163520 Archived-At: > From: Sean Sieger > Date: Fri, 20 Sep 2013 12:34:28 -0400 > > Does the below work as expected? > > emacs -Q c*.c > > If you do this from the src directory, you should end up with visiting > the 14 C files that match the wildcard in the Emacs's src directory. > What do you get in Emacs linked with the new MinGW runtime? > > Wait, wait, wait ... > > MinGW-Shell: > > Sean@blah /c/trunk/src/ > $ emacs -Q c*.c > > ... I get the correct result. In the MSYS Bash, the shell does the wildcard expansion, that's why you get correct results. > Command Prompt: > > c:\trunk\src>emacs -Q c*.c > > ... nope, visits the non-existent, `c*.c'. Right, as I expected. Here's why: MinGW runtime v4.x changed the layout of 'struct dirent', the structure returned by 'readdir', in an incompatible way. Where previously we had struct dirent { long d_ino; /* Always zero. */ unsigned short d_reclen; /* Always zero. */ unsigned short d_namlen; /* Length of name in d_name. */ char d_name[FILENAME_MAX]; /* File name. */ }; we now have struct dirent { long d_ino; /* Always zero. */ unsigned short d_reclen; /* Always zero. */ unsigned short d_namlen; /* Length of name in d_name. */ /* The following exactly mimic the layout of _finddata_t ... */ unsigned d_type; /* File attributes */ time_t d_time_create; time_t d_time_access; /* always midnight local time */ time_t d_time_write; _fsize_t d_size; /* * ...so that we may map a union of _finddata_t at the * location of d_type (corresponding to _finddata_t.attrib), * and thus map this directly to the _findfirst/_findnext * returned field. */ char d_name[FILENAME_MAX]; /* File name. */ }; As you see d_name[] moved, and is now at a different offset. That in itself is already a bad idea, because linking a program with a library that was compiled with an older version of dirent.h will now produce a buggy program, which will look for the file name in a wrong place. However, it might still be OK for Emacs, because Emacs has its own definition of 'struct dirent' and its own implementation of 'readdir', and thus does not use the ones provided by the MinGW runtime. But then the MinGW developers added insult to injury, by calling 'readdir' from the startup code. This is an absolute no-no for a library, because a C program can legitimately have an incompatible function named 'readdir' that might even have nothing to do with reading a directory. What happens in Emacs as result is that the startup code calls the Emacs implementation of 'readdir', which uses an incompatible 'struct dirent', and the result is that globbing of wildcards is broken. At the time, I tried to convince the MinGW developers not to do this, here: http://sourceforge.net/mailarchive/message.php?msg_id=29278605 http://sourceforge.net/mailarchive/message.php?msg_id=30712991 http://sourceforge.net/mailarchive/message.php?msg_id=30715094 http://sourceforge.net/mailarchive/message.php?msg_id=30854291 Evidently, I failed completely to convince them, as the incompatible runtime went to print regardless, and the problems will now begin unfolding before our eyes...