Packaging Emacs with native compilation enabled

Packaging Emacs with native compilation enabled

[Bhavin Gandhi]

This is the first time I'm creating a new thread on this list. Sorry, if
this is not the correct place to discuss this.

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?

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. And those will be created when Emacs
starts on the end user's machine.

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.

I think those .eln files are required. If so, is it okay to package and
distribute these .eln files along with the emacs binary?

If this is already discussed / documented somewhere, can anyone please
point me to that resource?

[1] https://emacsconf.org/2021/talks/native/

-- 
Regards,
Bhavin Gandhi (bhavin192) | https://geeksocket.in

Re: Packaging Emacs with native compilation enabled

[Eli Zaretskii]

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

Re: Packaging Emacs with native compilation enabled

[Bhavin Gandhi]

On Sun, 5 Dec 2021 at 19:30, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

Thanks! Now I'm able to make sense out of the conversations about
keeping NATIVE_FULL_AOT=1 when building the binary distribution
packages.

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

Understood, that makes sense. And clarifies the following line from the
manual.

> The transportability of natively-compiled code is the same as that of
> shared libraries (‘.so’ or ‘.dll’ files).