bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60996: 29.0.60; Native compile fails to remove temp file for trampol


From: Andrea Corallo
Subject: bug#60996: 29.0.60; Native compile fails to remove temp file for trampoline
Date: Thu, 26 Jan 2023 19:46:25 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: andrewjmoreton@gmail.com, 60996@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]