GNU bug report logs - #47800
[native-comp] could not resolve realpath of "emacs"

Previous Next

Full log

Message #49 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 19:23:51 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
>> Date: Fri, 16 Apr 2021 09:27:51 +0000
>> 
>> > But I can at least confirm that the issue is that raw_name is not
>> > resolved according to PATH prior to the call of real_filename in
>> >
>> >   char *filename = real_filename (SSDATA (raw_name));
>> 
>> I agree that's the issue.
>
> I think the issue is slightly more complex.

That's very possible today I had really no time to reproduce and
investigate this in details sorry.

> Andrea, is native-compilation supported with unexec, or only with
> pdumper?

Only pdumper.

> If the former, where in the code and when do we load the
> preloaded *.eln files? are they dumped into the Emacs executable?

We re-load the eln for each compilation unit around pdumper.c:5277.  The
position of the eln is already stored in CU object (formed in
loadup.el:467).

> If we don't support native-compilation with unexec, we should reject
> that combination in configure, right?

That's correct.

Thanks

  Andrea

Previous Next

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