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

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.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 19:46:25 +0000

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

>> 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.

Agree, or at least I hope (otherwise we have two problems in place of
one :).

>> 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.

Mmmhh, and what if another Emacs tries to delete or overwrite the same
file?

But my question is: is this mechanism _really_ necessary?

From my POV it's just a kludge that was, is and will be source of
problems.  Was never clear to me for which specific reason this was
implemented as, at the time, I had the impression that all Debian
requirements could be handled with what we already offered.

At the time I firmly opposed to this change, but I was told by Lars it
went into master "for discussion" (!?), indeed the review discussion
never happened...  and now we are left with this present.

Unless we have a very strong reason to keep it, I believe we should just
get rid of this mechanism, otherwise it will be source of pain for us
again and again in the future.

Best Regards

  Andrea

Previous Next

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