GNU bug report logs - #44701
28.0.50; [feature/native-comp] Use file-truename when building eln path hash

Previous Next

Package: emacs;

Reported by: Tad <tadfisher <at> gmail.com>

Date: Tue, 17 Nov 2020 04:25:01 UTC

Severity: normal

Found in version 28.0.50

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Tad <tadfisher <at> gmail.com>
Subject: bug#44701: closed (Re: bug#44701: 28.0.50; [feature/native-comp]
 Use file-truename when building eln path hash)
Date: Wed, 18 Nov 2020 20:58:01 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#44701: 28.0.50; [feature/native-comp] Use file-truename when building eln path hash

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 44701 <at> debbugs.gnu.org.

-- 
44701: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44701
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Andrea Corallo <akrl <at> sdf.org>
To: Tad <tadfisher <at> gmail.com>
Cc: 44701-done <at> debbugs.gnu.org
Subject: Re: bug#44701: 28.0.50; [feature/native-comp] Use file-truename
 when building eln path hash
Date: Wed, 18 Nov 2020 20:57:55 +0000
Tad <tadfisher <at> gmail.com> writes:

> This makes it possible to load AOT-compiled .eln files from the Nix
> store, so thank you for implementing this change.

That's good to hear!  Thank you for reporting, closing.

  Andrea

[Message part 3 (message/rfc822, inline)]
From: Tad <tadfisher <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: akrl <at> sdf.org
Subject: 28.0.50; [feature/native-comp] Use file-truename when building eln
 path hash
Date: Mon, 16 Nov 2020 20:03:15 -0800
It appears that `comp-el-to-eln-filename` uses `expand-file-name` to
determine the absolute filename to
hash. When the filename is a symlink, this results in a cache miss
depending on which path is loaded.

`file-truename' would be the equivalent to `(expand-file-name name
nil)`, except that it would resolve to a
single canonical path (in the absence of hardlinks, which is pathological).

If I may ask, what is the purpose behind the path component of the
hash? I would think a content hash
would suffice to disambiguate files in the .el<->.eln bijection.

Thanks,
Tad



This bug report was last modified 4 years and 247 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.