From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48578@debbugs.gnu.org
Subject: bug#48578: 28.0.50; Native-compiled files of some preloaded files not loaded at dump time
Date: Tue, 25 May 2021 12:34:27 +0000 [thread overview]
Message-ID: <xjfzgwjkn58.fsf@sdf.org> (raw)
In-Reply-To: <834kesdruz.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 May 2021 19:22:12 +0300")
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 48578@debbugs.gnu.org
>> Date: Mon, 24 May 2021 08:48:39 +0000
>>
>> > Suggestions for where to look for the reasons of the problem?
>>
>> I'd start verifying what given the el source file
>> `comp-el-to-eln-rel-filename' suggests as eln filename and if this is
>> present as native compiled file (I guess so if you recompiled manually).
>>
>> The next step would be verifying why when loading in lread.c
>> 'maybe_swap_for_eln' does not decide to load the eln file in place of
>> the elc one.
>
> Thanks. The problem is in comp-el-to-eln-rel-filename, in this
> fragment at its beginning:
>
> /* Use `file-truename' or fall back to `expand-file-name' when the
> first is not available (bug#44701).
>
> `file-truename' is not available only for a short phases of the
> bootstrap before file.el is loaded, given we do not symlink
> inside the build directory this should work. */
> filename = NILP (Ffboundp (intern_c_string ("file-truename")))
> ? Fexpand_file_name (filename, Qnil)
> : CALL1I (file-truename, filename);
>
> During loadup, file-truename is not available until files.elc/eln is
> loaded. But the assumption above that it isn't a problem because "we
> do not symlink inside the build directory" in false in my case,
> because my home directory, where I build Emacs, is itself a symlink:
>
> (expand-file-name "~") => "/home/e/eliz"
> (file-truename "~") => "/srv/data/home/e/eliz"
>
> So every one of the *.eln files loaded before and including files.elc
> will fail in the above logic and will produce a different path_hash,
> thus failing the attempt to find the correct .eln file.
>
> We could use 'realpath' (and a suitable emulation on WINDOWSNT)
> instead of file-truename.
Hi Eli,
I see, it would then look something like the attached I guess.
It does bootstrap on GNU/Linux but I'm no expert on how to fill the
WINDOWSNT ifdef branch.
Thanks
Andrea
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 48578.patch --]
[-- Type: text/x-diff, Size: 1380 bytes --]
diff --git a/src/comp.c b/src/comp.c
index 340ed85038..e6debefa1d 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -4008,15 +4008,23 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename,
{
CHECK_STRING (filename);
- /* Use `file-truename' or fall back to `expand-file-name' when the
- first is not available (bug#44701).
-
- `file-truename' is not available only for a short phases of the
- bootstrap before file.el is loaded, given we do not symlink
- inside the build directory this should work. */
- filename = NILP (Ffboundp (intern_c_string ("file-truename")))
- ? Fexpand_file_name (filename, Qnil)
- : CALL1I (file-truename, filename);
+ /* Use `file-truename' or fall back to 'realpath' `expand-file-name'
+ when the first is not available. (`file-truename' is not
+ available only for a short phases of the bootstrap before file.el
+ is loaded). */
+
+ if (NILP (Ffboundp (intern_c_string ("file-truename"))))
+ {
+#ifndef WINDOWSNT
+ char *file_normalized = realpath (SSDATA (filename), NULL);
+#else
+ char *file_normalized = ??? ;
+#endif
+ filename = Fexpand_file_name (build_string (file_normalized), Qnil);
+ xfree (file_normalized);
+ }
+ else
+ filename = CALL1I (file-truename, filename);
if (NILP (Ffile_exists_p (filename)))
xsignal1 (Qfile_missing, filename);
next prev parent reply other threads:[~2021-05-25 12:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-22 7:20 bug#48578: 28.0.50; Native-compiled files of some preloaded files not loaded at dump time Eli Zaretskii
2021-05-24 6:55 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-24 7:30 ` Eli Zaretskii
2021-05-24 7:47 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-24 8:10 ` Eli Zaretskii
2021-05-24 8:48 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-24 16:22 ` Eli Zaretskii
2021-05-25 12:34 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-05-25 13:02 ` Eli Zaretskii
2021-05-25 13:18 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-25 13:22 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-26 13:43 ` Eli Zaretskii
2021-05-27 11:57 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-27 13:45 ` Eli Zaretskii
2021-05-29 7:02 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-29 8:57 ` Eli Zaretskii
2021-05-25 18:13 ` Basil L. Contovounesios
2021-05-25 18:15 ` Eli Zaretskii
2021-05-25 18:31 ` Basil L. Contovounesios
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjfzgwjkn58.fsf@sdf.org \
--to=bug-gnu-emacs@gnu.org \
--cc=48578@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).