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

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

bug#49118: 28.0.50; Error: File error Opening output file


From: Andrea Corallo
Subject: bug#49118: 28.0.50; Error: File error Opening output file
Date: Mon, 21 Jun 2021 10:21:25 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 49118@debbugs.gnu.org
>> From: Manuel Uberti <manuel.uberti@inventati.org>
>> Date: Sat, 19 Jun 2021 16:34:41 +0200
>> 
>> On 19/06/21 16:32, Eli Zaretskii wrote:
>> > What happens if you invoke the native-compilation like this:
>> > 
>> >    $ emacs -batch -l comp -f batch-native-compile 
>> > /usr/local/share/emacs/28.0.50/lisp/time.el.gz
>> > 
>> > Does this also fail, and if so, what error message(s) do you see?
>> 
>> This is what I get:
>> 
>> manuel@hathaway:~$ emacs -batch -l comp -f batch-native-compile 
>> /usr/local/share/emacs/28.0.50/lisp/time.el.gz
>> uncompressing time.el.gz...
>> uncompressing time.el.gz...done
>> Debugger entered--Lisp error: (file-error 
>> "/usr/local/share/emacs/28.0.50/lisp/time.el.gz" "Opening output file" 
>> "Cannot 
>> overwrite file" "/usr/local/share/emacs/28.0.50/lisp/time.elc")
>>    signal(file-error ("/usr/local/share/emacs/28.0.50/lisp/time.el.gz" 
>> "Opening 
>> output file" "Cannot overwrite file" 
>> "/usr/local/share/emacs/28.0.50/lisp/time.elc"))
>>    comp--native-compile("/usr/local/share/emacs/28.0.50/lisp/time.el.gz")
>>    batch-native-compile()
>>    command-line-1(("-l" "comp" "-f" "batch-native-compile" 
>> "/usr/local/share/emacs/28.0.50/lisp/time.el.gz"))
>>    command-line()
>>    normal-top-level()
>
> Thanks.
>
> Andrea, this means bug#48978 was not entirely fixed: we are still
> trying to write the *.elc files when native-compiling.  Your last
> change prevented Emacs from trying to create a temporary file under
> /usr/share/emacs, but it didn't prevent the rest of byte-compile-file
> from trying to overwrite the original .elc file, which here causes us
> to signal an error.  We need to avoid writing the .elc file entirely
> in this case, I think.

Hi Eli,

agreed, hopefully a4fb5811fa does a better job at this, please have a
look.

Thanks

  Andrea





reply via email to

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