emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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