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: Fri, 5 Mar 2021 10:09:47 +0000 Message-ID: References: <86wnutogrh.fsf@gmail.com> <86wnut8fb9.fsf@gmail.com> <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> 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="24399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 05 11:11: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 1lI7QL-0006FF-T3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Mar 2021 11:11:09 +0100 Original-Received: from localhost ([::1]:60330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI7QK-0002Zy-Uz for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Mar 2021 05:11:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lI7QE-0002Zj-Gz for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 05:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lI7QE-0005o9-9O for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 05:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lI7QE-0001yg-3T for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 05:11: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: Fri, 05 Mar 2021 10:11: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.16149390327553 (code B ref 46256); Fri, 05 Mar 2021 10:11:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 5 Mar 2021 10:10:32 +0000 Original-Received: from localhost ([127.0.0.1]:32928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI7Pk-0001xl-Gy for submit@debbugs.gnu.org; Fri, 05 Mar 2021 05:10:32 -0500 Original-Received: from mail-ot1-f48.google.com ([209.85.210.48]:46999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI7Ph-0001xW-JQ for 46256@debbugs.gnu.org; Fri, 05 Mar 2021 05:10:30 -0500 Original-Received: by mail-ot1-f48.google.com with SMTP id 97so1234151otf.13 for <46256@debbugs.gnu.org>; Fri, 05 Mar 2021 02:10:29 -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=sbSOnJ7CS19GoQxTFVCkkfQ/EQotMX6YbyplmaGLZ1g=; b=CI9HLCDzvUzvAMlgKpTw1+VZx0r8y0y4DNPfAIKYuauKqlpfE5LIlySvf/OAE20MvD U287c0QzA9bY6zpZExDy0jXGN8E395KUVZbka2P7KoArI3Qt8PWHCAcHnSzT79JCIjg8 996hIl3Dp8ejxBe1EyOutKwBSlRr81uzaESpNErB3dnhb4Q2rLUd/vVch1wRB7CXgqUb ROT5Uyn9X0Hlds7PUzR3j1gydeH8dWowGvcmTt4hB9wzsXnxDIUhH3QJL2JE68HxLId3 Rwi20/pZ84iPBGBQP4GTWMk2lksNRRbEtLpQYsMcG53LqKLWWhVhoCj9mMAPedSagYPd HwWw== 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=sbSOnJ7CS19GoQxTFVCkkfQ/EQotMX6YbyplmaGLZ1g=; b=Nv9fysCUZZF6TJMOKtInBSlAQe0B271d3cna3IBTtgDpb1towlt+Ssi0rpSnaOdnh7 KD5jpoB/86+kcRb3V2MfSylX0w1UBZsvE/44LrF6D3coP9O6vC4QHSN/C5d8F/4fxL2s TIPSZ2EB+Qc0feee6Jkcmg9dPaJB/FAwnxkO4h6p2JPBb53RkA4Vy+PoOCkvGL1ja0Rq xZZX3pudn47Z/lLvSuhV+yQPHuvYl6gcQdIKQp5znlQgefuYc9pK1ainOrZt/7zUF9hH 4RrmuQwucqLjs/t7mPVgx4rttKQmzfFjeNAuJ4lMjeib/hBuU95SD6fee2hiMPOvsFfr EUhA== X-Gm-Message-State: AOAM5323fJZen7OxqSjCSXkPwOOmMUvuRVRQJJVyhf/RD85VVv1g9X07 5plMdwl7jIDeiZ2V1fiZYYbtViBhZhA7TST2y08= X-Google-Smtp-Source: ABdhPJxgozDDM0U1uJMRW2bYaEXRIdRcBElhLeEoZq5dKp8xpef1M2WKwPClaeI2TYbMO6ZKggxgV48rCXBCmvpfyl0= X-Received: by 2002:a05:6830:1011:: with SMTP id a17mr5126069otp.154.1614939023782; Fri, 05 Mar 2021 02:10:23 -0800 (PST) In-Reply-To: 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:201516 Archived-At: On Fri, Mar 5, 2021 at 9:33 AM Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Eli Zaretskii writes: > > So currently the only way to fill up a newly created subdirectory of > > native-lisp/ is to manually delete the *.elc files of all the files in > > lisp.mk's $shortlisp list, is that sufficient? > > Yes I think so. > > The trouble of using make for building such a system is that make is not > aware of the .eln filename, so it should be necessary to ask the Emacs > binary about that to create dynamically the precise (multiple target) > rule. Not very practical IMO... I do wonder whether the whole filename scheme is really the best option. IIUC, and that's a big if in this case, the main motivation for using hashes in the .eln filenames is that dlopen() is broken and may return the same handle for subsequent dlopen()s of the same name, even if the underlying file changed in between. 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 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. Pip