GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: 41242 <at> debbugs.gnu.org, akrl <at> sdf.org, nicolasbertolo <at> gmail.com
Subject: bug#41242: Port feature/native-comp to Windows
Date: Thu, 14 May 2020 13:45:20 +0300

On May 14, 2020 1:18:26 PM GMT+03:00, Andrea Corallo <akrl <at> sdf.org> wrote:
> Nicolas Bértolo <nicolasbertolo <at> gmail.com> writes:
> 
> > * `package-delete` fails because it tries to delete the .eln file
> via
> >   `delete-file`. This is impossible in Windows because it's
> generally impossible
> >   to delete files that have an open HANDLE in the system.
> >
> >   Three solutions have crossed my mind:
> >
> >   - Edit `package-delete` to put the eln on a list of files that
> should be
> >     deleted when Emacs is closed.
> >
> >   - Implement an unloading mechanism for native-compiled files.
> >
> >   - Copy eln files to temporary files and load those temporary files
> instead.
> >     This means that deleting the original eln file is possible.
> >
> >   I'd prefer the second option, but I have a semi-working patch for
> the third
> >   option.
> 
> I don't think the second is an option.  The unload machanism is
> already
> in place but is GC driven, I don't see how else it could work.

Windows doesn't let you delete a shared library that's loaded by a process, but it does let you rename it.  So I think the solution would be to rename the .eln file to something like .eln.old, and then let the GC driven unload machinery to delete that old file.

Btw, what happens if more than one Emacs session have the same .eln file loaded, and one of them wants to recompile it?

Previous Next

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