From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master fails to build on FreeBSD when ACL support is on Date: Fri, 19 Jan 2018 20:45:04 +0200 Message-ID: <83lggtu1qn.fsf@gnu.org> References: <86o9lua0yx.fsf@phe.ftfl.ca> <834lnly8ht.fsf@gnu.org> <86vafy20sj.fsf@phe.ftfl.ca> <83o9lpuct5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1516387470 8263 195.159.176.226 (19 Jan 2018 18:44:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 18:44:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 19 19:44:26 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecbe8-00012L-31 for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 19:44:12 +0100 Original-Received: from localhost ([::1]:37707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecbg7-0003UH-Jv for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 13:46:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecbfW-0003Tz-Nd for emacs-devel@gnu.org; Fri, 19 Jan 2018 13:45:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecbfR-0003aJ-RX for emacs-devel@gnu.org; Fri, 19 Jan 2018 13:45:38 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecbfR-0003aF-Ng; Fri, 19 Jan 2018 13:45:33 -0500 Original-Received: from [176.228.60.248] (port=2460 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ecbfP-0007oD-RG; Fri, 19 Jan 2018 13:45:33 -0500 In-reply-to: (message from Stefan Monnier on Fri, 19 Jan 2018 11:38:56 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:222090 Archived-At: > From: Stefan Monnier > Date: Fri, 19 Jan 2018 11:38:56 -0500 > > > - (make-temp-file (file-name-nondirectory target-file))) > > + ;; If target-file is relative and includes > > + ;; leading directories, make-temp-file will > > + ;; assume those leading directories exist > > + ;; under temporary-file-directory, which might > > + ;; not be true. So strip leading directories > > + ;; from relative file names before calling > > + ;; make-temp-file. > > + (if (file-name-absolute-p target-file) > > + (make-temp-file target-file) > > + (make-temp-file > > + (file-name-nondirectory target-file)))) > > Hmm.. the comment here doesn't explain the (file-name-absolute-p > target-file) test, and the commit message It doesn't? > + ;; If target-file is relative and includes ^^^^^^^^^^^^^^^^^^^^^^^^^^ > IIUC the core of the problem has to do with different ACLs in /tmp and > the final destination of the .elc file, but it seems like this problem > should apply regardless of whether that final destination is specified > as a relative or an absolute file name, right? Yes, the change doesn't fix the ACL problem on FreeBSD, it just allows Emacs to be built on that system. I don't know enough about FreeBSD ACLs to fix the general problem, and such a solution wouldn't be appropriate for the release branch anyway. > So maybe rather than (file-name-absolute-p target-file) we should check > something related to ACLs, or (eq system-type 'feebsd-foo)? No, the change in bytecomp.el is a step in the right direction anyway, as it's closer to what the code did before my previous change (which uncovered the FreeBSD problem). > Or maybe we should just never use /tmp and just go with > > (make-temp-file (expand-file-name target-file)) > > ? Why is that better? Once again, the general ACL problem on FreeBSD needs to be investigated and solved, perhaps by declaring that system unfit for using ACLs (if worse comes to worst). Any other "solution" is just a workaround, so they all just side-step the issue.