[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packaging Emacs with native compilation enabled
From: |
Eli Zaretskii |
Subject: |
Re: Packaging Emacs with native compilation enabled |
Date: |
Sun, 05 Dec 2021 16:00:31 +0200 |
> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Sun, 5 Dec 2021 19:02:08 +0530
>
> I'm packaging the 28.0.90 pretest as RPM with native compilation
> enabled. The `make install' installs some .eln files to lib64 directory
> i.e. /usr/lib64/emacs/28.0.90/native-lisp/28.0.90-<hash>/.
>
> 1. Should these files be there in the final package, which is
> distributed to users?
If you are making a binary distribution (not one where users will have
to build Emacs from sources), these files should be included, yes.
> Based on what I have understood from Andrea's EmacsConf 2021 talk[1] and
> the "(elisp) Native Compilation" page: the .eln files are CPU specific
> and should not be shared across.
That's true, but you are already producing Emacs binaries, which are
necessarily specific to the CPU, right? The *.eln files are just
shared libraries built for the same architecture as the Emacs binary,
so they have the same restrictions as the binary.
> With that in mind, I deleted the *.eln files from the package. But when
> I start emacs-nox (the one without X), it gives this error:
>
> $ emacs-nox -Q
> Error using execdir /usr/bin/:
> emacs:
> /usr/bin/../native-lisp/28.0.90-f21cc02e/preloaded/frame-b40fc590-e67d4a02.eln:
> cannot open shared object file: No such file or directory
>
> If I add the 28.0.90-f21cc02e directory to the lib64 directory
> mentioned above, it starts correctly. I can see the path in
> `native-comp-eln-load-path' variable.
That's expected. Emacs dumped with *.eln files will not start if the
preloaded *.eln files are removed.