From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Sat, 6 Mar 2021 09:54:22 +0000 Message-ID: References: <861rd1tbpa.fsf@gmail.com> <83pn0km6y3.fsf@gnu.org> <86ft1f8ara.fsf@gmail.com> <83sg5cjdn8.fsf@gnu.org> <83r1kwjcy2.fsf@gnu.org> <83k0qoj9zv.fsf@gnu.org> <83im68j963.fsf@gnu.org> <83tuprhur0.fsf@gnu.org> <831rcu25o2.fsf@gnu.org> <83v9a6zr22.fsf@gnu.org> <83o8fyzjrz.fsf@gnu.org> <86sg593vfm.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39799"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org To: Andy Moreton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 06 10:56:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lITfN-000AEd-Lf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 10:56:09 +0100 Original-Received: from localhost ([::1]:44684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lITfM-0003H0-EI for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 04:56:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35116) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lITfG-0003Go-D2 for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 04:56:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52735) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lITfG-0004fL-5c for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 04:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lITfG-0005rd-4m for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 04:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Mar 2021 09:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46256 X-GNU-PR-Package: emacs Original-Received: via spool by 46256-submit@debbugs.gnu.org id=B46256.161502450722468 (code B ref 46256); Sat, 06 Mar 2021 09:56:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 6 Mar 2021 09:55:07 +0000 Original-Received: from localhost ([127.0.0.1]:36048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lITeM-0005qK-RD for submit@debbugs.gnu.org; Sat, 06 Mar 2021 04:55:07 -0500 Original-Received: from mail-oi1-f171.google.com ([209.85.167.171]:41419) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lITeK-0005pn-Lh for 46256@debbugs.gnu.org; Sat, 06 Mar 2021 04:55:05 -0500 Original-Received: by mail-oi1-f171.google.com with SMTP id y131so2557757oia.8 for <46256@debbugs.gnu.org>; Sat, 06 Mar 2021 01:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/c5PvP1KjW6HC1HIc1W9m6A7S/zatoo6sNettaOW/Yg=; b=M0W+rpCGpUaUSeZubmp9ZTuoBLxX7qIDtKZdVRW/SqKKtGW9ydLEwEDT315iMoCZS+ GyV9rQ8M+tHDUyoDQTZIQzuPUj0IIi6FmRy8M6rAkTwyW5Kg9ykauM3eMXyaUvMh3vuF 8ldsTnovin3K1Ni9M2jz2ISZg6cH9+sfYcYw9mlB70qzif/PFrYsPxUNxQdzeIyW2SHn +WplbbbMJc7r2BrSoihfgNU3qc/sS8xXaZPg6Ps7e+Qx6xe2qWFKUEqT+62HE5psAXvF B4DZJpyqnuN+SHBWRD6NMWB2+v17aXI6Z+fNioEjwYpnxZq60/0SjWTL7EA221whLHOm yeCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/c5PvP1KjW6HC1HIc1W9m6A7S/zatoo6sNettaOW/Yg=; b=WjBjpDU0EDB+L2Bn3MryaPSb0iO0SZypiJkI1ehcUm3Vy5ntkTRzdtp0Q+5YDHkY4v TBpl4vy5oNHgRa73E81n1pA9POvSfQ4EzNpguzqDUY+e64fCiGLdUkdq6eqGzM6ItkJp br18zA8LV1y3zOeiwGf0P+CBEItFcruLPp16SNDrctEQmifWv7oKXqQGjK3EMDW/egZ6 IcQz2FuYQW0Z9CQ2FBqXDarWdvcw3jNIomf2svYE+yMdJ8fk65v4JJMQP4OzLgUcL1dU hAonQLSFnrXkNVoI4GQOEPHIlddVDt7/ntwJ1Wz1t/2TDAwGGGTN9lwYp+leyl6tQWvp zg8A== X-Gm-Message-State: AOAM530nI76fQXxhMZ0zPrbfQ0aK66C1cD9EzwPxbbm7H2EUR5OL/W5L T7AQ81EdcWOcGqab6gJ27QfkVJl5Vy3boI7SuW0= X-Google-Smtp-Source: ABdhPJwbMgpJJ3xNggtvyYxqDbGmwSJw4k0cPXDZBoh8KIS4m1g/q2I8+Ixrl1Ok7C8Lxgwvm2tDUrl6h44d6pJl2GQ= X-Received: by 2002:aca:d905:: with SMTP id q5mr10013382oig.30.1615024498977; Sat, 06 Mar 2021 01:54:58 -0800 (PST) In-Reply-To: <86sg593vfm.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201605 Archived-At: On Sat, Mar 6, 2021 at 1:48 AM Andy Moreton wrote: > On Fri 05 Mar 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: [Does anyone know where this via "name" comes from? I believe it is Google's joke which somehow makes it through into the gmail interface...] > Is the problem that dlopen resolves to use an unlinked file kept alive > by having open handles, rather than a new file with the filename used > by the old file before it was unlinked ? I believe so, and that's what I think we can work around. IIUC, we don't actually call dlclose() until we GC (and might not do so even then, since GC is conservative). > >> Merely verifying that the ABI is correct could be done at runtime, so > >> that's no reason to keep a hash in the filename. > >> > >> So my vague idea is this: > >> > >> 1. implement fixed_dlopen(), which keeps track of filenames that have > >> been opened and, if necessary, creates a temporary file and loads that > >> instead of its argument. > >> 2. compile lisp/emacs-lisp/bytecomp.el to lisp/emacs-lisp/bytecomp.elc > >> and native-lisp/emacs-lisp/bytecomp.eln > > > > So it was at the beginning, I think we moved away from that before the > > odd dlopen behavior. > > As above, this odd dlopen behaviour needs to be fully explained to > ensure that design choices are not driven by possible misunderstandings. I'm unsure what Andrea is saying here; is the dlopen thing relevant to the decision to use hashes in names, or isn't it? > >> 3. add extra code in the top level function of each .eln to check that > >> the ABI is correct. > >> > >> This would allow us to use standard make rules. It would also make > >> .eln filenames predictable. It might even draw someone's attention to > >> the fact that dlopen() is broken and make them fix it. > >> > >> I'm probably missing other good reasons for the hashed filename scheme. > > > > Yep, this was discussed in length on emacs-devel, IIRC mainly on a long > > standing thread called "native compilation the bird-eye view" (or > > something close). > > Thread "Native compilation: the bird-eye view" starts here: > https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg02186.html Thanks for the link. I do think it would be good to summarize the reasons for the hash-based naming scheme somewhere, because I've read the thread and all I've taken away is that the dlopen oddity requires a workaround (but, really, a different one). I don't think I've read all of the followup threads, though. > I agree with Pip that using standard make rules eases several development > pains and should be used if at all possible. What I think should be discussed, or should have been discussed, is whether we really need hashes in the names of files in the Emacs build tree. Whether we need them for installed files, or for files in the eln cache, is a separate issue. A second question is whether it's really worth it to build the elc and eln files at the same time. Make would be a lot happier not having two targets in the rule, and so would I. But if this has been discussed and resolved, we merely need to document the decision and the reasons for it rather than reopening discussion because I missed it the first time around. If someone can provide a link to the relevant messages, I'd be glad to try. Pip