From: Andrea Corallo <akrl@sdf.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: andrewjmoreton@gmail.com, 60996@debbugs.gnu.org
Subject: bug#60996: 29.0.60; Native compile fails to remove temp file for trampoline
Date: Thu, 26 Jan 2023 19:46:25 +0000 [thread overview]
Message-ID: <xjfwn5984fi.fsf@ma.sdf.org> (raw)
In-Reply-To: <83r0vhcf9m.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Jan 2023 20:38:45 +0200")
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
next prev parent reply other threads:[~2023-01-26 19:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 22:12 bug#60996: 29.0.60; Native compile fails to remove temp file for trampoline Andy Moreton
2023-01-22 6:17 ` Eli Zaretskii
2023-01-22 12:51 ` Andy Moreton
2023-01-23 17:04 ` Andrea Corallo
2023-01-23 17:11 ` Eli Zaretskii
2023-01-26 16:50 ` Andrea Corallo
2023-01-26 18:38 ` Eli Zaretskii
2023-01-26 19:46 ` Andrea Corallo [this message]
2023-01-26 20:03 ` Eli Zaretskii
2023-01-26 20:25 ` Andrea Corallo
2023-01-27 13:00 ` Eli Zaretskii
2023-01-27 13:56 ` Andrea Corallo
2023-01-26 20:35 ` Eli Zaretskii
2023-01-27 9:51 ` Andrea Corallo
2023-01-28 21:15 ` Andy Moreton
2023-01-29 7:01 ` Eli Zaretskii
2023-01-29 7:23 ` Eli Zaretskii
2023-01-30 10:11 ` Andrea Corallo
2023-01-29 7:47 ` Eli Zaretskii
2023-01-29 11:37 ` Andy Moreton
2023-01-29 13:50 ` Eli Zaretskii
2023-01-29 13:50 ` Eli Zaretskii
2023-01-23 2:30 ` Andy Moreton
2023-01-23 14:58 ` Eli Zaretskii
2023-01-24 1:18 ` Andy Moreton
2023-01-24 12:56 ` Eli Zaretskii
2023-01-24 17:50 ` Eli Zaretskii
2023-01-24 19:12 ` Eli Zaretskii
2023-01-24 22:32 ` Andy Moreton
2023-01-25 11:58 ` Eli Zaretskii
2023-01-25 23:49 ` Andy Moreton
2023-01-26 6:51 ` Eli Zaretskii
2023-01-26 16:57 ` Andrea Corallo
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=xjfwn5984fi.fsf@ma.sdf.org \
--to=akrl@sdf.org \
--cc=60996@debbugs.gnu.org \
--cc=andrewjmoreton@gmail.com \
--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).