bug#63681: closed (build error from native-comp: void function ("emacs-lisp/package.el" package-desc-p))

[GNU bug Tracking System]

Your message dated Mon, 5 Jun 2023 12:06:55 +0200
with message-id 
<CAO48Bk-pK3Vtc5VP7QWF8nqdRJ7uq4abegRpA74eZ3QbuiLZDQ@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@gnu.org.)


-- 
63710: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63710
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> build error from native-comp: void function ("emacs-lisp/package.el" package-desc-p)
>
>
>
>
> Date: 
>
> Wed, 24 May 2023 16:37:25 +0800
>
>
>
>
> 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
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#63710: use-package not working Date: Mon, 5 Jun 2023 12:06:55 +0200

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@gnu.org> wrote:

Andrea Corallo <acorallo@gnu.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Pedro Andres Aranda Gutierrez <paaguti@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

--- End Message ---