GNU bug report logs -
#64226
30.0.50; emacs-lisp-native-compile-and-load permission error
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64226 in the body.
You can then email your comments to 64226 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 15:17:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
No Wayman <iarchivedmywholelife <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 22 Jun 2023 15:17:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
To reproduce:
1. Find an elisp file located in $DIR which user has permission to
write to.
(in the following backtrace, the file being compiled was located
at $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el)
2. M-x emacs-lisp-native-compile-and-load
3. Observer the following error:
Error: permission-denied (\"Creating file with prefix\"
\"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
mapbacktrace(#f(compiled-function (evald func args flags)
#<bytecode 0x835cf36bbae8692>))
debug-early-backtrace()
debug-early(error (permission-denied \"Creating file with
prefix\" \"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
nil \".eln.tmp\" nil)
comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
comp-final1()
load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\" nil
t)
command-line-1((\"-l\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"))
command-line()
normal-top-level()
I would expect compiling this to not signal an error for a file I
have permission to write.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-06-19 built on laptop
Repository revision: edb0862f5e69240de90c30b8914af51778f26d31
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version
11.0.12101008
System Description: Arch Linux
I rebuilt from master and am still able to reproduce with
GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-06-21
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 15:35:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Date: Wed, 21 Jun 2023 12:58:40 -0400
>
>
> To reproduce:
>
> 1. Find an elisp file located in $DIR which user has permission to
> write to.
> (in the following backtrace, the file being compiled was located
> at $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el)
> 2. M-x emacs-lisp-native-compile-and-load
> 3. Observer the following error:
>
> Error: permission-denied (\"Creating file with prefix\"
> \"Permission denied\"
> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
> mapbacktrace(#f(compiled-function (evald func args flags)
> #<bytecode 0x835cf36bbae8692>))
> debug-early-backtrace()
> debug-early(error (permission-denied \"Creating file with
> prefix\" \"Permission denied\"
> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
> make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
> nil \".eln.tmp\" nil)
> comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
> comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
> comp-final1()
> load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"
> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\" nil
> t)
> command-line-1((\"-l\"
> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"))
> command-line()
> normal-top-level()
>
> I would expect compiling this to not signal an error for a file I
> have permission to write.
Is this in "emacs -Q"? If not, please see if "emacs -Q" reproduces
the problem.
I also don't understand why the backtrace above seems to imply that
you invoked Emacs like this:
emacs -l /tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el
IOW, the backtrace doesn't show invocation of
emacs-lisp-native-compile-and-load, it shows the attempt to load an
already-compiled .eln file. What am I missing? I added Andrea to
this discussion.
If, in "emacs -Q", you visit the source file, that is
$HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el
and then type
M-: (native-compile buffer-file-name) RET
what file name do you see in the echo-area after the compilation
finishes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 15:49:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Date: Wed, 21 Jun 2023 12:58:40 -0400
>>
>>
>> To reproduce:
>>
>> 1. Find an elisp file located in $DIR which user has permission
>> to
>> write to.
>> (in the following backtrace, the file being compiled was
>> located
>> at $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el)
>> 2. M-x emacs-lisp-native-compile-and-load
>> 3. Observer the following error:
>>
>> Error: permission-denied (\"Creating file with prefix\"
>> \"Permission denied\"
>> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
>> mapbacktrace(#f(compiled-function (evald func args flags)
>> #<bytecode 0x835cf36bbae8692>))
>> debug-early-backtrace()
>> debug-early(error (permission-denied \"Creating file with
>> prefix\" \"Permission denied\"
>> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
>> make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
>> nil \".eln.tmp\" nil)
>> comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
>> comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
>> comp-final1()
>> load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"
>> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"
>> nil
>> t)
>> command-line-1((\"-l\"
>> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el\"))
>> command-line()
>> normal-top-level()
>>
>> I would expect compiling this to not signal an error for a file
>> I
>> have permission to write.
> Is this in "emacs -Q"? If not, please see if "emacs -Q"
> reproduces
> the problem.
I have reproduced from emacs -Q as well. Same error as above:
Compiling /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el...done
comp--native-compile: Native compiler error:
"/home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el", "Compiling
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln...
Creating file with prefix: Permission denied,
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5
Error: permission-denied (\"Creating file with prefix\"
\"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
mapbacktrace(#f(compiled-function (evald func args flags)
#<bytecode 0x70d6f07f3ae8645>))
debug-early-backtrace()
debug-early(error (permission-denied \"Creating file with
prefix\" \"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
nil \".eln.tmp\" nil)
comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
comp-final1()
load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\" nil
t)
command-line-1((\"-l\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"))
command-line()
normal-top-level()
> I also don't understand why the backtrace above seems to imply
> that
> you invoked Emacs like this:
>
> emacs -l
> /tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el
> IOW, the backtrace doesn't show invocation of
> emacs-lisp-native-compile-and-load, it shows the attempt to load
> an
> already-compiled .eln file. What am I missing? I added Andrea
> to
> this discussion.
The compilation takes place in a subprocess, no?
That's probably how the subprocess is invoked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 16:13:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Andrea Corallo <acorallo <at> gnu.org>, 64226 <at> debbugs.gnu.org
> Date: Thu, 22 Jun 2023 11:44:33 -0400
>
> I have reproduced from emacs -Q as well. Same error as above:
>
>
> Compiling /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el...done
> comp--native-compile: Native compiler error:
> "/home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el", "Compiling
> /usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln...
> Creating file with prefix: Permission denied,
> /usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5
>
> Error: permission-denied (\"Creating file with prefix\"
> \"Permission denied\"
> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
> mapbacktrace(#f(compiled-function (evald func args flags)
> #<bytecode 0x70d6f07f3ae8645>))
> debug-early-backtrace()
> debug-early(error (permission-denied \"Creating file with
> prefix\" \"Permission denied\"
> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
> make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
> nil \".eln.tmp\" nil)
> comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
> comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
> comp-final1()
> load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"
> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\" nil
> t)
> command-line-1((\"-l\"
> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"))
> command-line()
> normal-top-level()
>
> > I also don't understand why the backtrace above seems to imply
> > that
> > you invoked Emacs like this:
> >
> > emacs -l
> > /tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el
>
> > IOW, the backtrace doesn't show invocation of
> > emacs-lisp-native-compile-and-load, it shows the attempt to load
> > an
> > already-compiled .eln file. What am I missing? I added Andrea
> > to
> > this discussion.
>
> The compilation takes place in a subprocess, no?
No, I don't think so, not with emacs-lisp-native-compile-and-load.
Andrea, am I right?
And you haven't answered my other question:
> If, in "emacs -Q", you visit the source file, that is
>
> $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el
>
> and then type
>
> M-: (native-compile buffer-file-name) RET
>
> what file name do you see in the echo-area after the compilation
> finishes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 16:31:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> No, I don't think so, not with
> emacs-lisp-native-compile-and-load.
> Andrea, am I right?
See comp-final:
(with-temp-buffer
(unwind-protect
(if (zerop
(call-process (expand-file-name invocation-name
invocation-directory)
nil t t "-no-comp-spawn" "-Q" "--batch" "-l"
temp-file))
(progn
(delete-file temp-file)
output)
(signal 'native-compiler-error (list (buffer-string))))
(comp-log-to-buffer (buffer-string))))))))
> And you haven't answered my other question:
>> If, in "emacs -Q", you visit the source file, that is
>>
>> $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el
>>
>> and then type
>>
>> M-: (native-compile buffer-file-name) RET
>>
>> what file name do you see in the echo-area after the
>> compilation
>> finishes?
The following file name is messaged with no error signaled:
"/home/n/.emacs.d/eln-cache/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 17:17:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
> Date: Thu, 22 Jun 2023 12:22:07 -0400
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > No, I don't think so, not with
> > emacs-lisp-native-compile-and-load.
> > Andrea, am I right?
>
> See comp-final:
That's not compilation, that's code generation, the last stage of
compilation.
> >> If, in "emacs -Q", you visit the source file, that is
> >>
> >> $HOME/.emacs.d/elpaca/builds/elpaca/elpaca.el
> >>
> >> and then type
> >>
> >> M-: (native-compile buffer-file-name) RET
> >>
> >> what file name do you see in the echo-area after the
> >> compilation
> >> finishes?
>
> The following file name is messaged with no error signaled:
>
> "/home/n/.emacs.d/eln-cache/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln"
Which is exactly what emacs-lisp-native-compile-and-load does. So I
wonder what went wrong in your case.
What is the value of native-comp-eln-load-path?
Also, can you show the contents of the file being compiled, which
seems to be /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el ?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 17:38:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> What is the value of native-comp-eln-load-path?
("/home/n/.emacs.d/eln-cache/"
"/usr/lib/emacs/30.0.50/native-lisp/")
> Also, can you show the contents of the file being compiled,
> which
> seems to be /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el ?
I can reproduce with any elisp file.
e.g. $HOME/test.el containing:
--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-
(defun +test () (message "PASS"))
--8<---------------cut here---------------end--------------->8---
Native compiler error: "/home/n/test.el", "Compiling
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab.eln...
Creating file with prefix: Permission denied,
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab
Error: permission-denied (\"Creating file with prefix\"
\"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab\")
mapbacktrace(#f(compiled-function (evald func args flags)
#<bytecode 0xd45c107f3ae87e6>))
debug-early-backtrace()
debug-early(error (permission-denied \"Creating file with
prefix\" \"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab\"))
make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab\"
nil \".eln.tmp\" nil)
comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab.eln\")
comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-98b414c9-ac29ecab.eln\")
comp-final1()
load-with-code-conversion(\"/tmp/emacs-int-comp-test-98b414c9-ac29ecab-my5A7o.el\"
\"/tmp/emacs-int-comp-test-98b414c9-ac29ecab-my5A7o.el\" nil t)
command-line-1((\"-l\"
\"/tmp/emacs-int-comp-test-98b414c9-ac29ecab-my5A7o.el\"))
command-line()
normal-top-level()
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Thu, 22 Jun 2023 17:54:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
> Date: Thu, 22 Jun 2023 13:21:49 -0400
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What is the value of native-comp-eln-load-path?
>
> ("/home/n/.emacs.d/eln-cache/"
> "/usr/lib/emacs/30.0.50/native-lisp/")
>
>
> > Also, can you show the contents of the file being compiled,
> > which
> > seems to be /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el ?
>
> I can reproduce with any elisp file.
> e.g. $HOME/test.el containing:
>
> --8<---------------cut here---------------start------------->8---
> ;; -*- lexical-binding: t; -*-
> (defun +test () (message "PASS"))
> --8<---------------cut here---------------end--------------->8---
Then I'm stumped, and hope Andrea will be able to figure this out. I
cannot reproduce the problem on my system, FWIW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sun, 25 Jun 2023 14:45:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Cc: Andrea Corallo <acorallo <at> gnu.org>, 64226 <at> debbugs.gnu.org
>> Date: Thu, 22 Jun 2023 11:44:33 -0400
>>
>> I have reproduced from emacs -Q as well. Same error as above:
>>
>>
>> Compiling /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el...done
>> comp--native-compile: Native compiler error:
>> "/home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el", "Compiling
>> /usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln...
>> Creating file with prefix: Permission denied,
>> /usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5
>>
>> Error: permission-denied (\"Creating file with prefix\"
>> \"Permission denied\"
>> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\")
>> mapbacktrace(#f(compiled-function (evald func args flags)
>> #<bytecode 0x70d6f07f3ae8645>))
>> debug-early-backtrace()
>> debug-early(error (permission-denied \"Creating file with
>> prefix\" \"Permission denied\"
>> \"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"))
>> make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5\"
>> nil \".eln.tmp\" nil)
>> comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
>> comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-1256ece5.eln\")
>> comp-final1()
>> load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"
>> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\" nil
>> t)
>> command-line-1((\"-l\"
>> \"/tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-oSdhiB.el\"))
>> command-line()
>> normal-top-level()
>>
>> > I also don't understand why the backtrace above seems to imply
>> > that
>> > you invoked Emacs like this:
>> >
>> > emacs -l
>> > /tmp/emacs-int-comp-elpaca-0646d6fc-1256ece5-73Dpd0.el
>>
>> > IOW, the backtrace doesn't show invocation of
>> > emacs-lisp-native-compile-and-load, it shows the attempt to load
>> > an
>> > already-compiled .eln file. What am I missing? I added Andrea
>> > to
>> > this discussion.
>>
>> The compilation takes place in a subprocess, no?
>
> No, I don't think so, not with emacs-lisp-native-compile-and-load.
> Andrea, am I right?
We always invoke libgccjit in a subprocess, the difference between sync
and async is:
- in sync compilation we run all our compiler *but* libgccjit in process
(libgccjit runs in a subprocess)
- in async all the compilation computation is done in a sub process.
The reason for running libgccjit always in a subprocess is that
unfortunatelly it leaks memory.
Best Regards
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sun, 25 Jun 2023 15:03:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
>> Date: Thu, 22 Jun 2023 13:21:49 -0400
>>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > What is the value of native-comp-eln-load-path?
>>
>> ("/home/n/.emacs.d/eln-cache/"
>> "/usr/lib/emacs/30.0.50/native-lisp/")
>>
>>
>> > Also, can you show the contents of the file being compiled,
>> > which
>> > seems to be /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el ?
>>
>> I can reproduce with any elisp file.
>> e.g. $HOME/test.el containing:
>>
>> --8<---------------cut here---------------start------------->8---
>> ;; -*- lexical-binding: t; -*-
>> (defun +test () (message "PASS"))
>> --8<---------------cut here---------------end--------------->8---
>
> Then I'm stumped, and hope Andrea will be able to figure this out. I
> cannot reproduce the problem on my system, FWIW.
That's very bizzare to me as well, I can't reproduce this either. Is
anyone able to reproduce this?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 01 Jul 2023 08:37:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Ping! Can anyone reproduce this issue and report the details, please?
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>, 64226 <at> debbugs.gnu.org
> Date: Sun, 25 Jun 2023 11:02:41 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> >> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
> >> Date: Thu, 22 Jun 2023 13:21:49 -0400
> >>
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > What is the value of native-comp-eln-load-path?
> >>
> >> ("/home/n/.emacs.d/eln-cache/"
> >> "/usr/lib/emacs/30.0.50/native-lisp/")
> >>
> >>
> >> > Also, can you show the contents of the file being compiled,
> >> > which
> >> > seems to be /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el ?
> >>
> >> I can reproduce with any elisp file.
> >> e.g. $HOME/test.el containing:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> ;; -*- lexical-binding: t; -*-
> >> (defun +test () (message "PASS"))
> >> --8<---------------cut here---------------end--------------->8---
> >
> > Then I'm stumped, and hope Andrea will be able to figure this out. I
> > cannot reproduce the problem on my system, FWIW.
>
> That's very bizzare to me as well, I can't reproduce this either. Is
> anyone able to reproduce this?
>
> Thanks
>
> Andrea
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 01 Jul 2023 15:33:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Can anyone reproduce this issue and report the details,
> please?
Still reproducible on my end on two machines:
1. GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-06-28
2. GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-06-15
Native compiler error:
"/home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el", "Compiling
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95.eln...
Creating file with prefix: Permission denied,
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95
Error: permission-denied (\"Creating file with prefix\"
\"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95\")
mapbacktrace(#f(compiled-function (evald func args flags)
#<bytecode 0x1e734bf67ae8647>))
debug-early-backtrace()
debug-early(error (permission-denied \"Creating file with
prefix\" \"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95\"))
make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95\"
nil \".eln.tmp\" nil)
comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95.eln\")
comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/elpaca-0646d6fc-bfea2b95.eln\")
comp-final1()
load-with-code-conversion(\"/tmp/emacs-int-comp-elpaca-0646d6fc-bfea2b95-SXTWTL.el\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-bfea2b95-SXTWTL.el\" nil
t)
command-line-1((\"-l\"
\"/tmp/emacs-int-comp-elpaca-0646d6fc-bfea2b95-SXTWTL.el\"))
command-line()
normal-top-level()
"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 01 Jul 2023 15:42:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Andrea Corallo <acorallo <at> gnu.org>, 64226 <at> debbugs.gnu.org
> Date: Sat, 01 Jul 2023 11:28:49 -0400
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Ping! Can anyone reproduce this issue and report the details,
> > please?
>
> Still reproducible on my end on two machines:
Thanks, but that's a small wonder: we didn't yet do anything to fix
this, whatever it is.
I was asking others to provide details, not just reproduce. If you
want to provide those details, perhaps you could describe how to
reproduce starting from "emacs -Q" (and loading any packages or
features you need for the minimal reproduction recipe). The way you
were showing the problem until now obviously depends on your local
setup, which is impossible to reproduce without knowing the details.
The main aspect of this which is completely unclear is: how come Emacs
tries to write in the /usr/lib tree when compiling Lisp files from
your home directory. This is not supposed to happen: Emacs should
write to the eln-cache subdirectory of your ~/.emacs.d/ directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 01 Jul 2023 20:53:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> perhaps you could describe how to
> reproduce starting from "emacs -Q" (and loading any packages or
> features you need for the minimal reproduction recipe). The way
> you
> were showing the problem until now obviously depends on your
> local
> setup, which is impossible to reproduce without knowing the
> details.
The instructions I gave here:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg01224.html
reproduce the error on my end from emacs -Q with a minimal file.
To be crystal clear:
1. Save the following file to $HOME/test.el (or any path where the
user has write permissions):
--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-
(defun +test () (message "PASS"))
--8<---------------cut here---------------end--------------->8---
2. emacs -Q $HOME/test.el
3. M-x emacs-lisp-native-compile-compile-and-load
4. Error is printed to message buffer.
I'm not sure how I can meaningfully pare it down from there.
> The main aspect of this which is completely unclear is: how come
> Emacs
> tries to write in the /usr/lib tree when compiling Lisp files
> from
> your home directory. This is not supposed to happen: Emacs
> should
> write to the eln-cache subdirectory of your ~/.emacs.d/
> directory.
That makes sense to me and I agree.
It looks like the critical path is in the file
`comp-spill-lap-function' method.
The comp-ctxt-output slot is set to (car (last
native-comp-eln-load-path)).
I don't know enough about the native-comp machinery to say whether
or not this is the appropriate solution, but let-binding
`native-compile-target-directory' to the car of
native-comp-eln-load-path in emacs-lisp-native-compile-and-load
compiles in the correct directory and avoids the error:
(defun emacs-lisp-native-compile-and-load ()
"Native-compile synchronously the current file (if it has
changed).
Load the compiled code when finished.
Use `emacs-lisp-byte-compile-and-load' in combination with
`native-comp-jit-compilation' set to t to achieve asynchronous
native compilation."
(interactive nil emacs-lisp-mode)
(emacs-lisp--before-compile-buffer)
(let ((byte+native-compile t)
(native-compile-target-directory (car
native-comp-eln-load-path))
(byte-to-native-output-buffer-file nil))
(when-let ((eln (native-compile buffer-file-name)))
(load (file-name-sans-extension (comp-write-bytecode-file
eln))))))
I'll leave the work of a proper patch to someone who is more
familiar with the system.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sun, 02 Jul 2023 06:00:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
> Date: Sat, 01 Jul 2023 15:14:16 -0400
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > perhaps you could describe how to reproduce starting from "emacs
> > -Q" (and loading any packages or features you need for the minimal
> > reproduction recipe). The way you were showing the problem until
> > now obviously depends on your local setup, which is impossible to
> > reproduce without knowing the details.
>
> The instructions I gave here:
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg01224.html
>
> reproduce the error on my end from emacs -Q with a minimal file.
> To be crystal clear:
>
> 1. Save the following file to $HOME/test.el (or any path where the
> user has write permissions):
>
> --8<---------------cut here---------------start------------->8---
> ;; -*- lexical-binding: t; -*-
> (defun +test () (message "PASS"))
> --8<---------------cut here---------------end--------------->8---
>
> 2. emacs -Q $HOME/test.el
> 3. M-x emacs-lisp-native-compile-compile-and-load
> 4. Error is printed to message buffer.
Thanks. I think Andrea couldn't reproduce this, but maybe he could
try again. (The error will only happen if the directory
usr/lib/emacs/30.0.50/native-lisp is not writable by your user, so
ensuring it's not writable should be part of the recipe.)
Also, please show the backtrace corresponding to the above recipe.
The backtrace you posted mentions files like
/home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el, but there's no
reference to $HOME/elpaca/repos in your recipe above. So I presume
the backtrace with the above recipe will mention different files, and
it is important to see those file names.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sun, 02 Jul 2023 06:19:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Also, please show the backtrace corresponding to the above
> recipe.
> The backtrace you posted mentions files like
> /home/n/.emacs.d/elpaca/repos/elpaca/elpaca.el, but there's no
> reference to $HOME/elpaca/repos in your recipe above. So I
> presume
> the backtrace with the above recipe will mention different
> files, and
> it is important to see those file names.
I sincerely doubt that will show anything more than what has been
demonstrated already.
Here you are from emacs -Q /tmp/test.el (contents mentioned in
last message):
Compiling /tmp/test.el...done
comp--native-compile: Native compiler error: "/tmp/test.el",
"Compiling
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab.eln...
Creating file with prefix: Permission denied,
/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab
Error: permission-denied (\"Creating file with prefix\"
\"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab\")
mapbacktrace(#f(compiled-function (evald func args flags)
#<bytecode -0x6de363c98517970>))
debug-early-backtrace()
debug-early(error (permission-denied \"Creating file with
prefix\" \"Permission denied\"
\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab\"))
make-temp-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab\"
nil \".eln.tmp\" nil)
comp--compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab.eln\")
comp-compile-ctxt-to-file(\"/usr/lib/emacs/30.0.50/native-lisp/30.0.50-58a66af6/test-53c62054-ac29ecab.eln\")
comp-final1()
load-with-code-conversion(\"/tmp/emacs-int-comp-test-53c62054-ac29ecab-s3wF7W.el\"
\"/tmp/emacs-int-comp-test-53c62054-ac29ecab-s3wF7W.el\" nil t)
command-line-1((\"-l\"
\"/tmp/emacs-int-comp-test-53c62054-ac29ecab-s3wF7W.el\"))
command-line()
normal-top-level()
"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Mon, 03 Jul 2023 08:52:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
>> Date: Sat, 01 Jul 2023 15:14:16 -0400
>>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > perhaps you could describe how to reproduce starting from "emacs
>> > -Q" (and loading any packages or features you need for the minimal
>> > reproduction recipe). The way you were showing the problem until
>> > now obviously depends on your local setup, which is impossible to
>> > reproduce without knowing the details.
>>
>> The instructions I gave here:
>>
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg01224.html
>>
>> reproduce the error on my end from emacs -Q with a minimal file.
>> To be crystal clear:
>>
>> 1. Save the following file to $HOME/test.el (or any path where the
>> user has write permissions):
>>
>> --8<---------------cut here---------------start------------->8---
>> ;; -*- lexical-binding: t; -*-
>> (defun +test () (message "PASS"))
>> --8<---------------cut here---------------end--------------->8---
>>
>> 2. emacs -Q $HOME/test.el
>> 3. M-x emacs-lisp-native-compile-compile-and-load
>> 4. Error is printed to message buffer.
>
> Thanks. I think Andrea couldn't reproduce this, but maybe he could
> try again. (The error will only happen if the directory
> usr/lib/emacs/30.0.50/native-lisp is not writable by your user, so
> ensuring it's not writable should be part of the recipe.)
Just retried and can finally reproduce the error. Will look at.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Wed, 09 Aug 2023 13:23:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>>> Cc: acorallo <at> gnu.org, 64226 <at> debbugs.gnu.org
>>> Date: Sat, 01 Jul 2023 15:14:16 -0400
>>>
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> > perhaps you could describe how to reproduce starting from "emacs
>>> > -Q" (and loading any packages or features you need for the minimal
>>> > reproduction recipe). The way you were showing the problem until
>>> > now obviously depends on your local setup, which is impossible to
>>> > reproduce without knowing the details.
>>>
>>> The instructions I gave here:
>>>
>>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-06/msg01224.html
>>>
>>> reproduce the error on my end from emacs -Q with a minimal file.
>>> To be crystal clear:
>>>
>>> 1. Save the following file to $HOME/test.el (or any path where the
>>> user has write permissions):
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> ;; -*- lexical-binding: t; -*-
>>> (defun +test () (message "PASS"))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> 2. emacs -Q $HOME/test.el
>>> 3. M-x emacs-lisp-native-compile-compile-and-load
>>> 4. Error is printed to message buffer.
>>
>> Thanks. I think Andrea couldn't reproduce this, but maybe he could
>> try again. (The error will only happen if the directory
>> usr/lib/emacs/30.0.50/native-lisp is not writable by your user, so
>> ensuring it's not writable should be part of the recipe.)
>
> Just retried and can finally reproduce the error. Will look at.
>
> Thanks
>
> Andrea
Okay I pushed b93107c20b2 to fix this. I tested as best as I could but
tweaking these dynamic variables is always tricky.
No Wayman if you could verify everything works for you would be great.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Wed, 09 Aug 2023 16:12:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Okay I pushed b93107c20b2 to fix this. I tested as best as I
> could but
> tweaking these dynamic variables is always tricky.
>
> No Wayman if you could verify everything works for you would be
> great.
>
> Thanks
>
> Andrea
Still present on:
GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-08-09
Fixed on:
GNU Emacs 29.1.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-08-09
Thank you.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 09 Aug 2023 16:30:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
No Wayman <iarchivedmywholelife <at> gmail.com>
:
bug acknowledged by developer.
(Wed, 09 Aug 2023 16:30:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 64226-done <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 64226 <at> debbugs.gnu.org
> Date: Wed, 09 Aug 2023 11:24:03 -0400
>
>
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
> > Okay I pushed b93107c20b2 to fix this. I tested as best as I
> > could but
> > tweaking these dynamic variables is always tricky.
> >
> > No Wayman if you could verify everything works for you would be
> > great.
> >
> > Thanks
> >
> > Andrea
>
> Still present on:
>
> GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.17.8) of 2023-08-09
That's expected, since the fix was installed on the emacs-29 branch,
and will be merged to master only in a couple of days.
Thanks for testing (and thanks to Andrea for fixing it), I'm therefore
closing this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 12 Aug 2023 09:19:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>, 64226 <at> debbugs.gnu.org
> Date: Wed, 09 Aug 2023 09:22:35 -0400
>
> Okay I pushed b93107c20b2 to fix this. I tested as best as I could but
> tweaking these dynamic variables is always tricky.
These changes broke building Emacs in the source tree: now all the
*.eln files produced by the build's ELC+ELN rule are written to the
user's eln-cache directory instead of into native-lisp subdirectory of
the build tree. To reproduce, touch, say, lisp/files.el or delete
lisp/files.elc, and then say "make" -- you will see that the *.eln
file is written under ~/.emacs.d/eln-cache, and if you also delete the
corresponding files-NNNN.eln file from native-lisp, Emacs will load
files.elc during loadup.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 12 Aug 2023 16:08:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>, 64226 <at> debbugs.gnu.org
>> Date: Wed, 09 Aug 2023 09:22:35 -0400
>>
>> Okay I pushed b93107c20b2 to fix this. I tested as best as I could but
>> tweaking these dynamic variables is always tricky.
>
> These changes broke building Emacs in the source tree: now all the
> *.eln files produced by the build's ELC+ELN rule are written to the
> user's eln-cache directory instead of into native-lisp subdirectory of
> the build tree. To reproduce, touch, say, lisp/files.el or delete
> lisp/files.elc, and then say "make" -- you will see that the *.eln
> file is written under ~/.emacs.d/eln-cache, and if you also delete the
> corresponding files-NNNN.eln file from native-lisp, Emacs will load
> files.elc during loadup.
Thanks, looking at it.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 12 Aug 2023 16:57:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 64226 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo <at> gnu.org>
>>> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>, 64226 <at> debbugs.gnu.org
>>> Date: Wed, 09 Aug 2023 09:22:35 -0400
>>>
>>> Okay I pushed b93107c20b2 to fix this. I tested as best as I could but
>>> tweaking these dynamic variables is always tricky.
>>
>> These changes broke building Emacs in the source tree: now all the
>> *.eln files produced by the build's ELC+ELN rule are written to the
>> user's eln-cache directory instead of into native-lisp subdirectory of
>> the build tree. To reproduce, touch, say, lisp/files.el or delete
>> lisp/files.elc, and then say "make" -- you will see that the *.eln
>> file is written under ~/.emacs.d/eln-cache, and if you also delete the
>> corresponding files-NNNN.eln file from native-lisp, Emacs will load
>> files.elc during loadup.
>
> Thanks, looking at it.
Okay, just pushed 842dbf500e0, seems to solve the issue here for me,
please have a look.
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64226
; Package
emacs
.
(Sat, 12 Aug 2023 17:23:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 64226 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: iarchivedmywholelife <at> gmail.com, 64226 <at> debbugs.gnu.org
> Date: Sat, 12 Aug 2023 12:56:38 -0400
>
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> From: Andrea Corallo <acorallo <at> gnu.org>
> >>> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>, 64226 <at> debbugs.gnu.org
> >>> Date: Wed, 09 Aug 2023 09:22:35 -0400
> >>>
> >>> Okay I pushed b93107c20b2 to fix this. I tested as best as I could but
> >>> tweaking these dynamic variables is always tricky.
> >>
> >> These changes broke building Emacs in the source tree: now all the
> >> *.eln files produced by the build's ELC+ELN rule are written to the
> >> user's eln-cache directory instead of into native-lisp subdirectory of
> >> the build tree. To reproduce, touch, say, lisp/files.el or delete
> >> lisp/files.elc, and then say "make" -- you will see that the *.eln
> >> file is written under ~/.emacs.d/eln-cache, and if you also delete the
> >> corresponding files-NNNN.eln file from native-lisp, Emacs will load
> >> files.elc during loadup.
> >
> > Thanks, looking at it.
>
> Okay, just pushed 842dbf500e0, seems to solve the issue here for me,
> please have a look.
Thanks, works correctly now.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 10 Sep 2023 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 286 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.