GNU bug report logs -
#63710
use-package not working
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 5 Jun 2023 12:06:55 +0200
with message-id <CAO48Bk-pK3Vtc5VP7QWF8nqdRJ7uq4abegRpA74eZ3QbuiLZDQ <at> mail.gmail.com>
and subject line Re: bug#63710: use-package not working
has caused the debbugs.gnu.org bug report #63710,
regarding build error from native-comp: void function ("emacs-lisp/package.el" package-desc-p)
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
63710: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63710
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi emacs,
With the latest emacs lisp native compiler change
(https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=92ccb6ba83076a40f3bfc7906913346a5b3a7a92
and subsequent commits), there is a build error:
```
Error: void-function ("emacs-lisp/package.el" package-desc-p)
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode
-0x1dc4ecf4b251797b>))
debug-early-backtrace()
debug-early(error (void-function "emacs-lisp/package.el" package-desc-p))
signal(void-function ("emacs-lisp/package.el" package-desc-p))
comp--native-compile("emacs-lisp/package.el")
batch-native-compile()
batch-byte+native-compile()
command-line-1(("--eval" "(setq load-prefer-newer t
byte-compile-warnings 'all)" "--eval" "(setq
org--inhibit-version-check t)" "-l" "comp" "-f"
"batch-byte+native-compile" "emacs-lisp/package.el"))
command-line()
normal-top-level()
Symbol’s function definition is void: "emacs-lisp/package.el", package-desc-p
```
I built Emacs master branch with the latest commit
(https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9ad997cd68981fe6c6933b6977fdae23e84e6a75),
enabled native-comp, on Linux.
Repository branch: master
System Description: Arch Linux
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-libotf --without-m17n-flt --without-gconf
--without-gsettings --enable-link-time-optimization
--with-native-compilation --with-pgtk --without-xaw3d --with-sound=alsa
--with-xwidgets --without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fuse-ld=gold'
CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
VitalyR
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
HI,
I was going to suggest it. I have rebuilt emacs w/native today and it seems
to be stable.
Thanks! /PA
On Mon, 5 Jun 2023 at 10:36, Andrea Corallo <acorallo <at> gnu.org> wrote:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
> > Andrea Corallo <akrl <at> sdf.org> writes:
> >
> >> Andrea Corallo <akrl <at> sdf.org> writes:
> >>
> >>> Pedro Andres Aranda Gutierrez <paaguti <at> gmail.com> writes:
> >>>
> >>>> First: the .emacs.d/init.el test file
> >>>>
> >>>> ------
> >>>> ;;
> >>>> ;; My .emacs file
> >>>> ;;
> >>>> (require 'package)
> >>>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> >>>> ("gnu" . "https://elpa.gnu.org/packages/")
> >>>> ("melpa-stable" . "
> https://stable.melpa.org/packages/")
> >>>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> >>>> (eval-when-compile
> >>>> (require 'use-package))
> >>>> (unless (file-directory-p package-user-dir)
> >>>> (package-refresh-contents))
> >>>> (require 'use-package-ensure)
> >>>> (setq use-package-always-ensure t)
> >>>>
> >>>> (use-package "compat")
> >>>> ------
> >>>>
> >>>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
> >>>>
> >>>> BTW, it has to do with native compilation. I have accidentally not
> deleted the eln-cache in on of the tests and the
> >>>> 'wrong' Emacs has started correctly:
> >>>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean
> cache ---> OK
> >>>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache
> from the last start --> OK
> >>>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean
> eln-cache ---> KO
> >>>
> >>>>From these SHA1s looks like there's good chance it's my fault...
> >>>
> >>> I'll have a look.
> >>
> >> Okay I did some investigation and understood the issue.
> >>
> >> `package-load-descriptor' was misscompiled and returning always nil as
> >> the compiler was not fully picking up the user defined types at compile
> >> time, it worked only after the first faulty compilation (thing that made
> >> the investigaiton a bit slower).
> >>
> >> I'm working on a more complete fix but this requires careful testing, I
> >> pushed now c8e527cbeee in order to have master stable again while I keep
> >> working on the most comprehensive fix.
> >
> > Okay RE-sending from this account and ditching my sdf.org probably
> > forever as I'm getting a bunch of bounces classifying it again as spam:
> >
> > Hi all,
> >
> > I pushed what I think is the final fix and reverted the temporary one.
> >
> > As of fbc96dcc4ea I'm not aware of any issue with package.el or other
> > code.
> >
> > Please let us know if works for you and we can close the bug or, if any
> > other issue arise (please remember to clean the eln-cache before testing
> > as it may contain misscompiled code ;).
>
> Okay one week passed since the fix was pushed and no more issues were
> reported on this, so I'm closing it. Happy to reopen in case.
>
> BR
>
> Andrea
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
[Message part 5 (text/html, inline)]
This bug report was last modified 2 years and 42 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.