GNU bug report logs - #60996
29.0.60; Native compile fails to remove temp file for trampoline

Previous Next

Package: emacs;

Reported by: Andy Moreton <andrewjmoreton <at> gmail.com>

Date: Sat, 21 Jan 2023 22:13:02 UTC

Severity: normal

Found in version 29.0.60

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

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: andrewjmoreton <at> gmail.com, 60996 <at> debbugs.gnu.org
Subject: Re: bug#60996: 29.0.60; Native compile fails to remove temp file
 for trampoline
Date: Thu, 26 Jan 2023 20:38:45 +0200
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: andrewjmoreton <at> gmail.com, 60996 <at> debbugs.gnu.org
> Date: Thu, 26 Jan 2023 16:50:59 +0000
> 
> What I've understood from the trace is that `comp--native-compile' is
> trying to delete the trampoline that was just compiled.
> 
> This is not expected in normal conditions so we have to understand why.
> 
> The only case where we might do that AFAIR is when
> `inhibit-automatic-native-compilation' is used.  This was the infamous
> mechanism that was installed by Lars where, if I'm not wrong, we are
> supposed to compile a trampoline, load it, and remove it to pretend we
> didn't compiled anything :x

OK, this seems to be what is happening here, because we compile the
trampoline to a temporary directory.  Otherwise, I don't see why we
would do that, and why we would delete a trampoline we just compiled.

> If (as I understand) in Windows we can't delete a mapped file we have a
> problem more to solve.

Yes.  If this is what happens, then I think we will have to maintain a
list of such trampolines, and delete them just before exiting, after
calling dynlib_close for them.




This bug report was last modified 2 years and 112 days ago.

Previous Next


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