Known case that emacs lisp code doesn't work correctly if native compilde

Known case that emacs lisp code doesn't work correctly if native compilde

[Yasuhiro Kimura]

Hello,

Mew is a mail reader for Emacs (http://www.mew.org/). I have been used
Mew as my mail readler for a while. But while testing native
compilation with FreeBSD amd64, I faced the problem that Mew doesn't
work correctly if .el files of Mew are native compiled.

I reported the problem to mailing list of Mew and recieved a reply
that Debian also faces it and works it around by setting
'no-native-compile' variable to 't' as file-local variable binding.
So it seems the problem is caused by native compilation itself and
isn't specific to some OS.

I would like to investigate it but probably it will take for a while.
So before starting it I would like to ask one question.

Is there any known case that some type of emacs lisp code doesn't work
correctly if it is native compiled?

Best Regards.

---
Yasuhiro Kimura

Re: Known case that emacs lisp code doesn't work correctly if native compilde

[Stefan Monnier]

> I would like to investigate it but probably it will take for a while.
> So before starting it I would like to ask one question.

I think you should open a bug report for that.

> Is there any known case that some type of emacs lisp code doesn't work
> correctly if it is native compiled?

IIRC native compilation recompiles the .el files instead of starting
from the .elc files, so if compilation of the .el to .elc is only
correct depending on specific packages being loaded in a specific order
it may happen that the native compilation will generate invalid code
(this is typically the case for large packages which force you to
compile the package via a `make` rule which takes care of preloading
the necessary files in the right order).

So far this has been a hypothetical problem, tho, so please report it so
we can better investigate.


        Stefan

Re: Known case that emacs lisp code doesn't work correctly if native compilde

[Yasuhiro Kimura]

From: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: Known case that emacs lisp code doesn't work correctly if native compilde
Date: Mon, 30 Aug 2021 15:14:28 -0400

> IIRC native compilation recompiles the .el files instead of starting
> from the .elc files, so if compilation of the .el to .elc is only
> correct depending on specific packages being loaded in a specific order
> it may happen that the native compilation will generate invalid code
> (this is typically the case for large packages which force you to
> compile the package via a `make` rule which takes care of preloading
> the necessary files in the right order).

Mew uses configure script and make to build and install it. So the
case of Mew seems fit for your explanation.

> So far this has been a hypothetical problem, tho, so please report it so
> we can better investigate.

OK, I'll submit bug report to Bug Tracker.

---
Yasuhiro Kimura

Re: Known case that emacs lisp code doesn't work correctly if native compilde

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1312 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:


I remember there was a thread on this earlier (one I perhaps started)
where there was an assertion that perhaps .eln files should be derived
from the .elc files, rather than from the .el files to avoid compilation
order issues.
>> I would like to investigate it but probably it will take for a while.
>> So before starting it I would like to ask one question.
>
> I think you should open a bug report for that.
>
>> Is there any known case that some type of emacs lisp code doesn't work
>> correctly if it is native compiled?
>
> IIRC native compilation recompiles the .el files instead of starting
> from the .elc files, so if compilation of the .el to .elc is only
> correct depending on specific packages being loaded in a specific order
> it may happen that the native compilation will generate invalid code
> (this is typically the case for large packages which force you to
> compile the package via a `make` rule which takes care of preloading
> the necessary files in the right order).
>
> So far this has been a hypothetical problem, tho, so please report it so
> we can better investigate.
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Known case that emacs lisp code doesn't work correctly if native compilde

[Stefan Monnier]

> I remember there was a thread on this earlier (one I perhaps started)
> where there was an assertion that perhaps .eln files should be derived
> from the .elc files, rather than from the .el files to avoid compilation
> order issues.

Indeed.


        Stefan

Re: Known case that emacs lisp code doesn't work correctly if native compilde

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1117 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:


this might be worth fixing before releasing emacs 28 with native
compilation turned on, I suspect other complex packages will break in a
similar manner.

For my own part, I stopped pursuing native compilation since most of the
speedup native comp gives you is with respect to visual updates (or at
least that is my suspicion) for me, it made no difference running
emacspeak and using speech output, and given that I had to do a bunch of
dances to build emacspeak correctly with native-comp, I just moved on
hoping it would get fixed when I wasn't looking (in the spirit of
Douglas Adams' SEP (Someone Else's Problem) -- it gets solved when you
look away:-)
>> I remember there was a thread on this earlier (one I perhaps started)
>> where there was an assertion that perhaps .eln files should be derived
>> from the .elc files, rather than from the .el files to avoid compilation
>> order issues.
>
> Indeed.
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8