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#20681: Build failure [MSYS2/MINGW64, OSX] Date: Sun, 31 May 2015 17:29:19 +0300 Message-ID: <83oal0u8g0.fsf@gnu.org> References: <55671056.9030604@alice.it> <83oal4wq59.fsf@gnu.org> <55685B1B.1040507@alice.it> <55689A39.7080804@cs.ucla.edu> <5568C1C8.2090406@cs.ucla.edu> <83siaeuzzk.fsf@gnu.org> <83lhg6uuyy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1433082637 27227 80.91.229.3 (31 May 2015 14:30:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 May 2015 14:30:37 +0000 (UTC) Cc: 20681@debbugs.gnu.org, eggert@cs.ucla.edu, nandryshak@gmail.com, angelo.graziosi@alice.it To: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 31 16:30:18 2015 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 1Yz4Fl-0007K3-VP for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 May 2015 16:30:18 +0200 Original-Received: from localhost ([::1]:42235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz4Fl-0004zw-7S for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 May 2015 10:30:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz4Fh-0004zg-Ec for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 10:30:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yz4Fe-0005mY-6O for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 10:30:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz4Fe-0005mU-3L for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 10:30:10 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yz4Fd-00061Z-7c for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 10:30:09 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 May 2015 14:30:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20681 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20681-submit@debbugs.gnu.org id=B20681.143308258023097 (code B ref 20681); Sun, 31 May 2015 14:30:08 +0000 Original-Received: (at 20681) by debbugs.gnu.org; 31 May 2015 14:29:40 +0000 Original-Received: from localhost ([127.0.0.1]:35006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yz4F9-00060R-Nz for submit@debbugs.gnu.org; Sun, 31 May 2015 10:29:40 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:50100) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yz4F5-00060B-2B for 20681@debbugs.gnu.org; Sun, 31 May 2015 10:29:36 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NP700K00XDO6V00@mtaout25.012.net.il> for 20681@debbugs.gnu.org; Sun, 31 May 2015 17:25:20 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NP700G5ZXE72R40@mtaout25.012.net.il>; Sun, 31 May 2015 17:25:20 +0300 (IDT) In-reply-to: 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:103395 Archived-At: > Date: Sat, 30 May 2015 15:06:16 +0200 > From: Andreas Grünbacher > Cc: Nick Andryshak , 20681@debbugs.gnu.org, > Paul Eggert , Angelo Graziosi > > > Please tell what do you want to see in confg.h, specifically. I can > > force the Emacs development head to compile set-permissions.c, so > > perhaps Emacs's config.h will do. > > It may. I have no idea what kind of acl functionality emacs on MinGW > should have though. Emacs built with MinGW has the same functionality on Windows as Emacs does on Posix hosts: get a file's ACL as a text string, set a file's ACL from text string description, and copy ACL from one file to another. The relevant functions, acl_get_file, acl_set_file, acl_to_text, acl_from_text, and acl_free are implemented as part of Emacs. > What did it do before? The only ACL-related function that Emacs on Windows was using from Gnulib was acl_errno_valid. All the rest were implemented in the Emacs sources. IOW, the Gnulib ACL functions were almost completely unused in the MinGW build. However, they did compile, which allowed us to keep the Gnulib configuration very similar to what was used on Posix hosts. Which is why I'm not sure it is worth your while to do more than you've already done, unless you do want to make sure the code at least compiles as it did before. With that caveat, I answer below your questions, regardless. > Is the build failure new or did it already exist before the acl > rewrite? It is new. Before the rewrite, the file qcopy-acl.c would compile with MinGW, although the function qcopy_acl was not called in the MinGW build, and so qcopy-acl.o was not linked into the binary. But it would at least compile. After the rewrite, qcopy-acl.c is just a thin wrapper around get-permissions.c and set-permissions.c. The former still compiles with MinGW, but the latter doesn't. The reason is this cpp conditional: # ifndef HAVE_ACL_DELETE_DEF_FILE # error Must have acl_delete_def_file (see POSIX 1003.1e draft 17). # endif I don't understand why the code requires acl_delete_def_file where it previously did not: it's not like setting permissions will absolutely not work if there is no such function. E.g., why not do something like the following instead: # ifndef HAVE_ACL_DELETE_DEF_FILE ret = -1; errno = ENOSYS; # else ret = acl_delete_def_file (name); # endif More generally, copying ACLs from one file to another does not need any analysis of what's in the ACLs being copied: it could simply treat the ACLs as an opaque object, something whose structure and semantics are known only to the innards of acl_get_file and acl_set_file. So building qcopy_acl on top of get_permissions and set_permissions, which are more flexible, and do require that knowledge, is IMO fundamentally wrong, as it makes much harder to port this simple and important Gnulib function to other platforms. After all, copying ACLs from one file to another is much more frequent and important an operation than setting ACLs from user-specified arguments. What's more, the assumption that if acl_get_file and acl_set_file are available, then so should be acl_delete_def_file is yet another obstacle, IMO gratuitous one. > Which acl related symbols do you have in config.h? HAVE_ACL_FREE HAVE_ACL_FROM_TEXT HAVE_ACL_GET_FILE HAVE_ACL_SET_FILE HAVE_SYS_ACL_H USE_ACL > If it has acl_get_file and acl_set_file, where can I find > documentation about what those functions do on MinGW? They do what you'd expect, but support only ACL_TYPE_ACCESS. They know about ACL_TYPE_DEFAULT, but always return EINVAL for it, since it's next to impossible (and not recommended) to have a directory on Windows which has no default ACLs associated with it. You can see their sources in src/w32.c in the Emacs repository. Thanks.