unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





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