bug#53497: 29.0.50; native-compile after restarting Emacs

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Hi all,

when I delete all .eln files in the directory specified by
`comp-native-version-dir' and re-start Emacs, "standard" libraries, the
ones I require in my .emacs and installed via package are native
compiled (in my case 77 .eln files).  The issue:

1) When I do `M-x gnus RET', Gnus' libraries get compiled.
2) When I re-start Emacs instead and then do `M-x gnus RET', the
   libraries are not re-compiled.

Am I missing something?  This is Emacs dee029e19f compiled on Win10.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> when I delete all .eln files in the directory specified by
> `comp-native-version-dir' and re-start Emacs, "standard" libraries, the
> ones I require in my .emacs and installed via package are native
> compiled (in my case 77 .eln files).  The issue:
>
> 1) When I do `M-x gnus RET', Gnus' libraries get compiled.
> 2) When I re-start Emacs instead and then do `M-x gnus RET', the
>    libraries are not re-compiled.
>
> Am I missing something?  This is Emacs dee029e19f compiled on Win10.

I'm not sure I understand.  Do you expect the .eln files to be
re-compiled every time?  They aren't re-compiled unless the source files
change.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Arash Esbati <arash@gnu.org> writes:
>
>> when I delete all .eln files in the directory specified by
>> `comp-native-version-dir' and re-start Emacs, "standard" libraries, the
>> ones I require in my .emacs and installed via package are native
>> compiled (in my case 77 .eln files).  The issue:
>>
>> 1) When I do `M-x gnus RET', Gnus' libraries get compiled.
>> 2) When I re-start Emacs instead and then do `M-x gnus RET', the
>>    libraries are not re-compiled.
>>
>> Am I missing something?  This is Emacs dee029e19f compiled on Win10.
>
> I'm not sure I understand.  Do you expect the .eln files to be
> re-compiled every time?  They aren't re-compiled unless the source files
> change.

Sorry if I wasn't clear.  In case 2, Gnus libraries are not compiled at
all and I stick with 77 .eln files.  In case 1, I go up to more than 100
.eln files.

Best, ARash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

>>> when I delete all .eln files in the directory specified by
>>> `comp-native-version-dir' and re-start Emacs, "standard" libraries, the
>>> ones I require in my .emacs and installed via package are native
>>> compiled (in my case 77 .eln files).  The issue:
>>>
>>> 1) When I do `M-x gnus RET', Gnus' libraries get compiled.
>>> 2) When I re-start Emacs instead and then do `M-x gnus RET', the
>>>    libraries are not re-compiled.
>>>
>>> Am I missing something?  This is Emacs dee029e19f compiled on Win10.
>>
>> I'm not sure I understand.  Do you expect the .eln files to be
>> re-compiled every time?  They aren't re-compiled unless the source files
>> change.
>
> Sorry if I wasn't clear.  In case 2, Gnus libraries are not compiled at
> all and I stick with 77 .eln files.  In case 1, I go up to more than 100
> .eln files.

So you delete `comp-native-version-dir' between 1) and 2)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So you delete `comp-native-version-dir' between 1) and 2)?

No, that was step 0.  I did:

Case 1)
- Killed Emacs
- Deleted all files in `comp-native-version-dir' 
- Started Emacs
- Waited for 77 .eln to be compiled under `comp-native-version-dir'
- Started Gnus
- Watched Gnus libraries getting compiled

Case 2)
- Killed Emacs
- Deleted all files in `comp-native-version-dir'
- Started Emacs
- Waited for 77 .eln to be compiled under `comp-native-version-dir'
- Killed Emacs
- Started Emacs
- Started Gnus
- No compilation happens under `comp-native-version-dir'

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Mon, 24 Jan 2022 12:00:23 +0100
> Cc: 53497@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > So you delete `comp-native-version-dir' between 1) and 2)?
> 
> No, that was step 0.  I did:
> 
> Case 1)
> - Killed Emacs
> - Deleted all files in `comp-native-version-dir' 

What exactly do you mean by comp-native-version-dir? it is not a full
directory name, and there should be 2 such directories in any Emacs
installation: one under lib/emacs/ and another under
~/.emacs.d/eln-cache/.  Which one did you delete?

More importantly, why do you delete that directory? what is the
purpose of that, and what did you expect to happen as result?

> - Started Emacs
> - Waited for 77 .eln to be compiled under `comp-native-version-dir'
> - Started Gnus
> - Watched Gnus libraries getting compiled
> 
> Case 2)
> - Killed Emacs
> - Deleted all files in `comp-native-version-dir'
> - Started Emacs
> - Waited for 77 .eln to be compiled under `comp-native-version-dir'
> - Killed Emacs
> - Started Emacs
> - Started Gnus
> - No compilation happens under `comp-native-version-dir'

Which of these 2 scenarios sounds problematic to you, and why?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Date: Mon, 24 Jan 2022 12:00:23 +0100
>> Cc: 53497@debbugs.gnu.org
>
> What exactly do you mean by comp-native-version-dir? it is not a full
> directory name, and there should be 2 such directories in any Emacs
> installation: one under lib/emacs/ and another under
> ~/.emacs.d/eln-cache/.  Which one did you delete?

I deleted only the files in ~/.emacs.d/eln-cache/, to be more accurate,
~/.emacs.d/eln-cache/29.0.50-e0a1564a.  I didn't touch the directly
itself.

> More importantly, why do you delete that directory? what is the
> purpose of that, and what did you expect to happen as result?

I had the impression that the deferred compilation doesn't work for me,
hence I deleted the files and played with the scenarios I described.

>> - Started Emacs
>> - Waited for 77 .eln to be compiled under `comp-native-version-dir'
>> - Started Gnus
>> - Watched Gnus libraries getting compiled
>> 
>> Case 2)
>> - Killed Emacs
>> - Deleted all files in `comp-native-version-dir'
>> - Started Emacs
>> - Waited for 77 .eln to be compiled under `comp-native-version-dir'
>> - Killed Emacs
>> - Started Emacs
>> - Started Gnus
>> - No compilation happens under `comp-native-version-dir'
>
> Which of these 2 scenarios sounds problematic to you, and why?

2) is problematic to me because Emacs doesn't compile libraries when I
use them after a re-start.  Gnus was only an example, it also doesn't
work when I load a .tex file with RefTeX enabled.  RefTeX libraries are
not compiled.  I basically stick with 77 .eln files forever.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Mon, 24 Jan 2022 11:35:38 +0100
> Cc: 53497@debbugs.gnu.org
> 
> >> Am I missing something?  This is Emacs dee029e19f compiled on Win10.

How did you compile Emacs? did you use NATIVE_FULL_AOT=1 to natively
compile all the bundled *.el files, or did you use the default build
procedure that only natively compile only the preloaded *.el files?

> Sorry if I wasn't clear.  In case 2, Gnus libraries are not compiled at
> all and I stick with 77 .eln files.  In case 1, I go up to more than 100
> .eln files.

If Emacs doesn't natively compile files it loads, it generally means
it cannot access the source *.el files, or that you load the *.el
files explicitly with the .el extension.

And I don't understand why the Gnus files need to be compiled each
time in the first place.  they aren't supposed to change, so they
should be natively compiled just once, when you first load them into
an Emacs session.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Date: Mon, 24 Jan 2022 11:35:38 +0100
>> Cc: 53497@debbugs.gnu.org
>> 
>> >> Am I missing something?  This is Emacs dee029e19f compiled on Win10.
>
> How did you compile Emacs? did you use NATIVE_FULL_AOT=1 to natively
> compile all the bundled *.el files, or did you use the default build
> procedure that only natively compile only the preloaded *.el files?

I only pass '--with-native-compilation' to configure.

>> Sorry if I wasn't clear.  In case 2, Gnus libraries are not compiled at
>> all and I stick with 77 .eln files.  In case 1, I go up to more than 100
>> .eln files.
>
> If Emacs doesn't natively compile files it loads, it generally means
> it cannot access the source *.el files, or that you load the *.el
> files explicitly with the .el extension.
>
> And I don't understand why the Gnus files need to be compiled each
> time in the first place.

That's not my issue.  I don't want the files to be compiled again and
again (see below).

> they aren't supposed to change, so they should be natively compiled
> just once, when you first load them into an Emacs session.

This is exactly my problem that files don't get compiled if I re-start
Emacs and then they are loaded (e.g. RefTeX).  It works only in the
first session when Emacs sees the empty ~/.emacs.d/eln-cache/ and starts
the machinery.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 13:50:19 +0100
> 
> > they aren't supposed to change, so they should be natively compiled
> > just once, when you first load them into an Emacs session.
> 
> This is exactly my problem that files don't get compiled if I re-start
> Emacs and then they are loaded (e.g. RefTeX).  It works only in the
> first session when Emacs sees the empty ~/.emacs.d/eln-cache/ and starts
> the machinery.

Doesn't happen here, so this is something specific to your system.

Does this happen if you start Emacs as "emacs -Q"?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't happen here,

Thanks for testing.

> so this is something specific to your system.

I build Emacs with a small script like this, nothing specific (AFAICT):

time ( \
    git clean -fdx --exclude=ChangeLog
    ./autogen.sh &&             \
    CPPFLAGS='-DNDEBUG'         \
    CFLAGS='-O3 -g0 -pipe'      \
    LDFLAGS='-s -Wl,-s'         \
    ./configure                 \
    --host=x86_64-w64-mingw32   \
    --target=x86_64-w64-mingw32 \
    --build=x86_64-w64-mingw32  \
    --with-jpeg                 \
    --with-gif                  \
    --with-xpm                  \
    --with-png                  \
    --with-tiff                 \
    --with-rsvg                 \
    --with-webp                 \
    --with-sqlite3              \
    --with-xml2                 \
    --with-gnutls               \
    --with-lcms2                \
    --with-modules              \
    --with-threads              \
    --with-native-compilation   \
    --with-native-image-api     \
    --without-imagemagick       \
    --without-dbus              \
    --without-gconf             \
    --without-gsettings         \
    --without-compress-install  \
    --without-mailutils         \
    --without-pop  &&           \
    make -j8 && make install prefix=/z/emacs-install )

> Does this happen if you start Emacs as "emacs -Q"?

This is what I tried:

- I killed Emacs
- Moved all files in ~/.emacs.d/eln-cache/ to another directory
- Started "emacs -Q"
- No native compilation at all in ~/.emacs.d/eln-cache/, not a single
 .eln is generated

I guess this is not the expected behavior, right?

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 14:33:25 +0100
> 
> I build Emacs with a small script like this, nothing specific (AFAICT):
> 
> time ( \
>     git clean -fdx --exclude=ChangeLog
>     ./autogen.sh &&             \
>     CPPFLAGS='-DNDEBUG'         \
>     CFLAGS='-O3 -g0 -pipe'      \
>     LDFLAGS='-s -Wl,-s'         \
>     ./configure                 \
>     --host=x86_64-w64-mingw32   \
>     --target=x86_64-w64-mingw32 \
>     --build=x86_64-w64-mingw32  \
>     --with-jpeg                 \
>     --with-gif                  \
>     --with-xpm                  \
>     --with-png                  \
>     --with-tiff                 \
>     --with-rsvg                 \
>     --with-webp                 \
>     --with-sqlite3              \
>     --with-xml2                 \
>     --with-gnutls               \
>     --with-lcms2                \
>     --with-modules              \
>     --with-threads              \
>     --with-native-compilation   \
>     --with-native-image-api     \
>     --without-imagemagick       \
>     --without-dbus              \
>     --without-gconf             \
>     --without-gsettings         \
>     --without-compress-install  \
>     --without-mailutils         \
>     --without-pop  &&           \
>     make -j8 && make install prefix=/z/emacs-install )

Why are you installing under a different prefix than used at configure
time?

> - I killed Emacs
> - Moved all files in ~/.emacs.d/eln-cache/ to another directory
> - Started "emacs -Q"
> - No native compilation at all in ~/.emacs.d/eln-cache/, not a single
>  .eln is generated
> 
> I guess this is not the expected behavior, right?

What did you do after starting "emacs -Q"?  It isn't enough to start
Emacs, you need to cause it to load some package before it will start
compiling that package.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> Date: Mon, 24 Jan 2022 15:45:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, 53497@debbugs.gnu.org
> 
> > - I killed Emacs
> > - Moved all files in ~/.emacs.d/eln-cache/ to another directory
> > - Started "emacs -Q"
> > - No native compilation at all in ~/.emacs.d/eln-cache/, not a single
> >  .eln is generated
> > 
> > I guess this is not the expected behavior, right?
> 
> What did you do after starting "emacs -Q"?  It isn't enough to start
> Emacs, you need to cause it to load some package before it will start
> compiling that package.

Btw, this could also be related to the problems I reported in
bug#52912.  Andrea, are you looking into that?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 24 Jan 2022 15:45:12 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: larsi@gnus.org, 53497@debbugs.gnu.org
>> 
>> > - I killed Emacs
>> > - Moved all files in ~/.emacs.d/eln-cache/ to another directory
>> > - Started "emacs -Q"
>> > - No native compilation at all in ~/.emacs.d/eln-cache/, not a single
>> >  .eln is generated
>> > 
>> > I guess this is not the expected behavior, right?
>> 
>> What did you do after starting "emacs -Q"?  It isn't enough to start
>> Emacs, you need to cause it to load some package before it will start
>> compiling that package.
>
> Btw, this could also be related to the problems I reported in
> bug#52912.  Andrea, are you looking into that?

Yes I'm looking into that, I suspect this is not related tho.

In this case if Emacs was installed the different prefix might have
Emacs not able to find the original source file?  I'm just speculating
but if this is the case we should have a warning emitted.

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: arash@gnu.org, larsi@gnus.org, 53497@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 14:27:19 +0000
> 
> > Btw, this could also be related to the problems I reported in
> > bug#52912.  Andrea, are you looking into that?
> 
> Yes I'm looking into that, I suspect this is not related tho.
> 
> In this case if Emacs was installed the different prefix might have
> Emacs not able to find the original source file?  I'm just speculating
> but if this is the case we should have a warning emitted.

Let's see.  Arash, could you please try reverting commits 6a79de5 and
9396b7d, install the Emacs you build without those two, and see if the
problem goes away?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Let's see.  Arash, could you please try reverting commits 6a79de5 and
> 9396b7d, install the Emacs you build without those two, and see if the
> problem goes away?

I checked out 1476b0d7a6 (which was the last commit before the two
above) and built Emacs twice: Once with my original recipe (pass prefix
to make install) and once passing --prefix to configure.  No avail with
both versions.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: Andrea Corallo <akrl@sdf.org>,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 18:17:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Let's see.  Arash, could you please try reverting commits 6a79de5 and
> > 9396b7d, install the Emacs you build without those two, and see if the
> > problem goes away?
> 
> I checked out 1476b0d7a6 (which was the last commit before the two
> above) and built Emacs twice: Once with my original recipe (pass prefix
> to make install) and once passing --prefix to configure.  No avail with
> both versions.

OK, thanks.

So I think the only way to make progress here is to run Emacs under
GDB, with a breakpoint in maybe_defer_native_compilation, and if and
when it breaks, see what goes on there.  In general, this breakpoint
should break as soon as you invoke some command that loads a .elc file
for which there's no corresponding .eln file.

I hope your Emacs is not stripped of debugging symbols; if it is,
please rebuild and install without stripping and with -g3 switch, and
run the resulting executable under GDB as described above.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> So I think the only way to make progress here is to run Emacs under
> GDB, with a breakpoint in maybe_defer_native_compilation, and if and
> when it breaks, see what goes on there.  In general, this breakpoint
> should break as soon as you invoke some command that loads a .elc file
> for which there's no corresponding .eln file.
>
> I hope your Emacs is not stripped of debugging symbols; if it is,
> please rebuild and install without stripping and with -g3 switch, and
> run the resulting executable under GDB as described above.

Thanks for the guidance.  I did that all and stared for some times at
it.  Since it doesn't emit an error and I'm not really familiar with the
code, I think I have to spend more time on this exercise.

I suggest I close this report for now and dig further, I can re-open
once I have something new.

OK for you?  Thanks again to you all.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Tue, 25 Jan 2022 12:01:35 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So I think the only way to make progress here is to run Emacs under
> > GDB, with a breakpoint in maybe_defer_native_compilation, and if and
> > when it breaks, see what goes on there.  In general, this breakpoint
> > should break as soon as you invoke some command that loads a .elc file
> > for which there's no corresponding .eln file.
> >
> > I hope your Emacs is not stripped of debugging symbols; if it is,
> > please rebuild and install without stripping and with -g3 switch, and
> > run the resulting executable under GDB as described above.
> 
> Thanks for the guidance.  I did that all and stared for some times at
> it.  Since it doesn't emit an error and I'm not really familiar with the
> code, I think I have to spend more time on this exercise.

You mean, the breakpoint in maybe_defer_native_compilation never
breaks?  That in itself is probably a sign of some problem.

> I suggest I close this report for now and dig further, I can re-open
> once I have something new.
> 
> OK for you?  Thanks again to you all.

There's no need to close it right away, unless you can no longer
reproduce the issue.  I'd prefer to close when we either understand
the reasons or the problem goes away by itself and becomes
unreproducible.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, the breakpoint in maybe_defer_native_compilation never
> breaks?  That in itself is probably a sign of some problem.

This is what I do and see:

-> gdb ./emacs RET
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
[...]
Reading symbols from ./emacs...
(gdb) break maybe_defer_native_compilation RET
Breakpoint 1 at 0x400241af0: file comp.c, line 5104.
(gdb) run -Q RET
Starting program: Z:\pathto\bin\emacs.exe -Q
[New Thread 9392.0x3f84]
[New Thread 9392.0x5758]
[New Thread 9392.0x1d48]
[New Thread 9392.0x53e8]
[New Thread 9392.0x51b0]

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=0xffff81f161684338, definition=0x1e782a44035) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
(gdb)

'Thread 1 hit Breakpoint 1' starts when I try to 'C-x C-f' a .tex file
in Emacs.  And then I can use n, s within the debugger.  But I don't get
any error and such.  Does this make sense to you?  I'm not really
familiar with GDB.

>> I suggest I close this report for now and dig further, I can re-open
>> once I have something new.
>> 
>> OK for you?  Thanks again to you all.
>
> There's no need to close it right away, unless you can no longer
> reproduce the issue.  I'd prefer to close when we either understand
> the reasons or the problem goes away by itself and becomes
> unreproducible.

Fine with me.  Currently, I can reproduce it reliably.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Tue, 25 Jan 2022 13:49:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You mean, the breakpoint in maybe_defer_native_compilation never
> > breaks?  That in itself is probably a sign of some problem.
> 
> This is what I do and see:
> 
> -> gdb ./emacs RET
> GNU gdb (GDB) 11.1
> Copyright (C) 2021 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./emacs...
> (gdb) break maybe_defer_native_compilation RET
> Breakpoint 1 at 0x400241af0: file comp.c, line 5104.
> (gdb) run -Q RET
> Starting program: Z:\pathto\bin\emacs.exe -Q
> [New Thread 9392.0x3f84]
> [New Thread 9392.0x5758]
> [New Thread 9392.0x1d48]
> [New Thread 9392.0x53e8]
> [New Thread 9392.0x51b0]
> 
> Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=0xffff81f161684338, definition=0x1e782a44035) at comp.c:5104
> 5104      if (!load_gccjit_if_necessary (false))
> (gdb)
> 
> 'Thread 1 hit Breakpoint 1' starts when I try to 'C-x C-f' a .tex file
> in Emacs.  And then I can use n, s within the debugger.  But I don't get
> any error and such.  Does this make sense to you?  I'm not really
> familiar with GDB.

Step through the code of maybe_defer_native_compilation with the 'n'
command, and see if it calls native--compile-async in this fragment:

  /* This is so deferred compilation is able to compile comp
     dependencies breaking circularity.  */
  if (!NILP (Ffeaturep (Qcomp, Qnil)))
    {
      /* Comp already loaded.  */
      if (!NILP (delayed_sources))
	{
	  CALLN (Ffuncall, intern_c_string ("native--compile-async"),
		 delayed_sources, Qnil, Qlate);
	  delayed_sources = Qnil;
	}
      Fputhash (function_name, definition, Vcomp_deferred_pending_h);
      CALLN (Ffuncall, intern_c_string ("native--compile-async"),
	     src, Qnil, Qlate);
    }

If the code exits the function before getting to this place, try to
figure out why.  It could fail to load libgccjit DLL, here:

  if (!load_gccjit_if_necessary (false))
    return;

Or it could exit due to one of the following conditions:

  if (!native_comp_deferred_compilation
      || noninteractive
      || !NILP (Vpurify_flag)
      || !COMPILEDP (definition)
      || !STRINGP (Vload_true_file_name)
      || !suffix_p (Vload_true_file_name, ".elc")
      || !NILP (Fgethash (Vload_true_file_name, V_comp_no_native_file_h, Qnil)))
    return;

Or it could exit because it doesn't find the Lisp source file:

  Lisp_Object src =
    concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
	     build_pure_c_string (".el"));
  if (NILP (Ffile_exists_p (src)))
    {
      src = concat2 (src, build_pure_c_string (".gz"));
      if (NILP (Ffile_exists_p (src)))
	return;
    }

Does one of these early returns indeed happen?

If not, i.e. if the code indeed calls native--compile-async, then you
should see a subprocess being started: native--compile-async calls
comp-run-async-workers, which calls make-process.  The code is in
comp.el.  If the subprocess is started, then JIT native-compilation
does work, and the question is what happens with the produced *.eln
files.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Step through the code of maybe_defer_native_compilation with the 'n'
> command, and see if it calls native--compile-async in this fragment:
>
>   /* This is so deferred compilation is able to compile comp
>      dependencies breaking circularity.  */
>   if (!NILP (Ffeaturep (Qcomp, Qnil)))
>     {
>       /* Comp already loaded.  */
>       if (!NILP (delayed_sources))
> 	{
> 	  CALLN (Ffuncall, intern_c_string ("native--compile-async"),
> 		 delayed_sources, Qnil, Qlate);
> 	  delayed_sources = Qnil;
> 	}
>       Fputhash (function_name, definition, Vcomp_deferred_pending_h);
>       CALLN (Ffuncall, intern_c_string ("native--compile-async"),
> 	     src, Qnil, Qlate);
>     }

This part looks like this for me:

  /* This is so deferred compilation is able to compile comp
     dependencies breaking circularity.  */
  if (comp__loadable)
    {
      /* Startup is done, comp is usable.  */
      Frequire (Qcomp, Qnil, Qnil);
      Fputhash (function_name, definition, Vcomp_deferred_pending_h);
      CALLN (Ffuncall, intern_c_string ("native--compile-async"),
	     src, Qnil, Qlate);
    }
  else
    Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);

> Does one of these early returns indeed happen?

No, early returns don't happen, but if (comp__loadable) goes into the
else part.  This is the part in GDB with Emacs b373c8ad71:

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=0xffff82e3c49e4338, definition=0x2d9d16a5345) at comp.c:5104
warning: Source file is more recent than executable.
5104      if (!load_gccjit_if_necessary (false))
(gdb) n
[New Thread 21916.0x5878]
5107      if (!native_comp_deferred_compilation
(gdb) n
5108          || noninteractive
(gdb) n
5109          || !NILP (Vpurify_flag)
(gdb) n
5110          || !COMPILEDP (definition)
(gdb) n
5111          || !STRINGP (Vload_true_file_name)
(gdb) n
5112          || !suffix_p (Vload_true_file_name, ".elc")
(gdb) n
5113          || !NILP (Fgethash (Vload_true_file_name, V_comp_no_native_file_h, Qnil)))
(gdb) n
5117        concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
(gdb) n
[New Thread 21916.0x2fb0]
5119      if (NILP (Ffile_exists_p (src)))
(gdb) n
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) n
5138    }

Again, many thanks for your patience.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Wed, 26 Jan 2022 12:25:43 +0100
> 
>   /* This is so deferred compilation is able to compile comp
>      dependencies breaking circularity.  */
>   if (comp__loadable)
>     {
>       /* Startup is done, comp is usable.  */
>       Frequire (Qcomp, Qnil, Qnil);
>       Fputhash (function_name, definition, Vcomp_deferred_pending_h);
>       CALLN (Ffuncall, intern_c_string ("native--compile-async"),
> 	     src, Qnil, Qlate);
>     }
>   else
>     Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
> 
> > Does one of these early returns indeed happen?
> 
> No, early returns don't happen, but if (comp__loadable) goes into the
> else part.  This is the part in GDB with Emacs b373c8ad71:

Andrea, can you explain how this is supposed to work?  comp--loadable
is set in startup.el, provided that comp--delayed-sources is non-nil,
but which code is supposed to put something into comp--delayed-sources
by the time we call startup--honor-delayed-native-compilations during
startup?

IOW, I'm not sure I understand how this is supposed to work.

> 5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
> (gdb) n

What is the value of Vcomp__delayed_sources?  You can display it like
this:

  (gdb) source /path/to/emacs/src/.gdbinit
  (gdb) pp Vcomp__delayed_sources

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> What is the value of Vcomp__delayed_sources?  You can display it like
> this:
>
>   (gdb) source /path/to/emacs/src/.gdbinit
>   (gdb) pp Vcomp__delayed_sources

5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp Vcomp__delayed_sources
No symbol "Vcomp__delayed_sources" in current context.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Wed, 26 Jan 2022 15:58:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is the value of Vcomp__delayed_sources?  You can display it like
> > this:
> >
> >   (gdb) source /path/to/emacs/src/.gdbinit
> >   (gdb) pp Vcomp__delayed_sources
> 
> 5128      if (comp__loadable)
> (gdb) n
> 5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
> (gdb) pp Vcomp__delayed_sources
> No symbol "Vcomp__delayed_sources" in current context.

This is a build with -g3?

Try this instead:

  (gdb) pp globals.f_Vcomp__delayed_sources

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a build with -g3?

Yes, I pass CFLAGS='-O0 -g3' to configure.

> Try this instead:
>
>   (gdb) pp globals.f_Vcomp__delayed_sources

5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
nil

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Wed, 26 Jan 2022 16:20:23 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is a build with -g3?
> 
> Yes, I pass CFLAGS='-O0 -g3' to configure.

Strange, it sounds like GDB cannot access macros,which -g3 should
allow.

> > Try this instead:
> >
> >   (gdb) pp globals.f_Vcomp__delayed_sources
> 
> 5128      if (comp__loadable)
> (gdb) n
> 5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
> (gdb) pp globals.f_Vcomp__delayed_sources
> nil

And it stays nil afterwards?  Or does it grow to include all the files
you expect to be natively-compiled as part of the session?  Is
maybe_defer_native_compilation called more than just once?  If so,
what is the value of Vcomp__delayed_sources for those other calls?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Strange, it sounds like GDB cannot access macros,which -g3 should
> allow.

This is Windows after all ;-)

> And it stays nil afterwards?

No, it doesn't (see below)

> Or does it grow to include all the files you expect to be
> natively-compiled as part of the session?  Is
> maybe_defer_native_compilation called more than just once?  If so,
> what is the value of Vcomp__delayed_sources for those other calls?

maybe_defer_native_compilation is called more than once.  This is the
result of multiple runs.  What remains is that the part to
"native--compile-async" is never called.

Below, [...] is always the repetition between
if (!load_gccjit_if_necessary (false))
and
if (comp__loadable)
which I've deleted.

--8<---------------cut here---------------start------------->8---
-> gdb ./emacs
GNU gdb (GDB) 11.1
[snipped]
(gdb) break maybe_defer_native_compilation
Breakpoint 1 at 0x400241af0: file comp.c, line 5104.
(gdb) source .gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 2 at 0x4001174a4: file emacs.c, line 406.
(gdb) run -Q
Starting program: Z:\path\to\emacs\src\emacs.exe -Q
[New Thread 8928.0x5f50]
[New Thread 8928.0xf60]
[New Thread 8928.0x5a44]
[New Thread 8928.0x4008]
[New Thread 8928.0x15bc]

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed63e350a0), definition=XIL(0x2e480e76535)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
(gdb) n
5107      if (!native_comp_deferred_compilation
(gdb) n
5108          || noninteractive
(gdb) n
5109          || !NILP (Vpurify_flag)
(gdb) n
5110          || !COMPILEDP (definition)
(gdb) n
5111          || !STRINGP (Vload_true_file_name)
(gdb) n
5112          || !suffix_p (Vload_true_file_name, ".elc")
(gdb) n
5113          || !NILP (Fgethash (Vload_true_file_name, V_comp_no_native_file_h, Qnil)))
(gdb) n
5117        concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
(gdb) n
5119      if (NILP (Ffile_exists_p (src)))
(gdb) n
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
[New Thread 8928.0x52dc]
nil
[New Thread 8928.0x3934]
(gdb) n
5138    }
(gdb) n
Fdefalias (symbol=XIL(0xffff82ed63e350a0), definition=XIL(0x2e480e76535), docstring=XIL(0)) at data.c:911
911       if (!NILP (docstring))
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed64253b58), definition=XIL(0x2e480e7fd85)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed63e6af00), definition=XIL(0x2e480e82325)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed64238900), definition=XIL(0x2e48103dd85)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed63dd9318), definition=XIL(0x2e480f0ae75)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed65497a20), definition=XIL(0x2e480fb9045)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed65497a80), definition=XIL(0x2e481019dd5)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) n
5138    }
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed65497a50), definition=XIL(0x2e481030f45)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) n
5138    }
(gdb) n
Fdefalias (symbol=XIL(0xffff82ed65497a50), definition=XIL(0x2e481030f45), docstring=XIL(0)) at data.c:911
911       if (!NILP (docstring))
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed65497ab0), definition=XIL(0x2e48104be45)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
[...]
5128      if (comp__loadable)
(gdb) n
5137        Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
(gdb) pp globals.f_Vcomp__delayed_sources
("z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/emacs-lisp/ring.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el" "z:/path/to/emacs/lisp/international/latexenc.el")
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, maybe_defer_native_compilation (function_name=XIL(0xffff82ed65497ae0), definition=XIL(0x2e48109dc45)) at comp.c:5104
5104      if (!load_gccjit_if_necessary (false))
(gdb) q
A debugging session is active.

        Inferior 1 [process 8928] will be killed.

Quit anyway? (y or n) y
--8<---------------cut here---------------end--------------->8---

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Wed, 26 Jan 2022 20:06:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Strange, it sounds like GDB cannot access macros,which -g3 should
> > allow.
> 
> This is Windows after all ;-)

No, it works for me on Windows, that's why I'm surprised.

> > And it stays nil afterwards?
> 
> No, it doesn't (see below)
> 
> > Or does it grow to include all the files you expect to be
> > natively-compiled as part of the session?  Is
> > maybe_defer_native_compilation called more than just once?  If so,
> > what is the value of Vcomp__delayed_sources for those other calls?
> 
> maybe_defer_native_compilation is called more than once.  This is the
> result of multiple runs.  What remains is that the part to
> "native--compile-async" is never called.

OK, so the list of deferred compilations grows, but no file is
actually being compiled for some reason.

Let's wait for Andrea to describe how it is supposed to work, and take
it from there.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
>> Date: Wed, 26 Jan 2022 12:25:43 +0100
>> 
>>   /* This is so deferred compilation is able to compile comp
>>      dependencies breaking circularity.  */
>>   if (comp__loadable)
>>     {
>>       /* Startup is done, comp is usable.  */
>>       Frequire (Qcomp, Qnil, Qnil);
>>       Fputhash (function_name, definition, Vcomp_deferred_pending_h);
>>       CALLN (Ffuncall, intern_c_string ("native--compile-async"),
>> 	     src, Qnil, Qlate);
>>     }
>>   else
>>     Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
>> 
>> > Does one of these early returns indeed happen?
>> 
>> No, early returns don't happen, but if (comp__loadable) goes into the
>> else part.  This is the part in GDB with Emacs b373c8ad71:
>
> Andrea, can you explain how this is supposed to work?

Hi Eli,

Sorry I'll probably not be able to read this thread and respond before
tomorrow, but I will.

BR

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
>> Date: Wed, 26 Jan 2022 12:25:43 +0100
>>
>>   /* This is so deferred compilation is able to compile comp
>>      dependencies breaking circularity.  */
>>   if (comp__loadable)
>>     {
>>       /* Startup is done, comp is usable.  */
>>       Frequire (Qcomp, Qnil, Qnil);
>>       Fputhash (function_name, definition, Vcomp_deferred_pending_h);
>>       CALLN (Ffuncall, intern_c_string ("native--compile-async"),
>> 	     src, Qnil, Qlate);
>>     }
>>   else
>>     Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
>>
>> > Does one of these early returns indeed happen?
>>
>> No, early returns don't happen, but if (comp__loadable) goes into the
>> else part.  This is the part in GDB with Emacs b373c8ad71:
>
> Andrea, can you explain how this is supposed to work?  comp--loadable
> is set in startup.el, provided that comp--delayed-sources is non-nil,
> but which code is supposed to put something into comp--delayed-sources
> by the time we call startup--honor-delayed-native-compilations during
> startup?

Before `comp--loadable' becomes true (read the native compiler is not
loadable) each time we enter in 'maybe_defer_native_compilation' we
accumulate the compilation units we want to compile in
`comp--delayed-sources'.

When we finally call `startup--honor-delayed-native-compilations' we
check if something is pending in `comp--delayed-sources' and if this is
the case we load the native compiler and we compile what's pending.

Unless I'm wrong the problem I see here is that if
`comp--delayed-sources' is empty we never set `comp--loadable' to t.
I'll be testing a patch today and report.

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Arash Esbati <arash@gnu.org>, larsi@gnus.org, 53497@debbugs.gnu.org
> Date: Thu, 27 Jan 2022 10:11:29 +0000
> 
> Before `comp--loadable' becomes true (read the native compiler is not
> loadable) each time we enter in 'maybe_defer_native_compilation' we
> accumulate the compilation units we want to compile in
> `comp--delayed-sources'.
> 
> When we finally call `startup--honor-delayed-native-compilations' we
> check if something is pending in `comp--delayed-sources' and if this is
> the case we load the native compiler and we compile what's pending.

Yes, I understood that much.  What I didn't understand was how would
comp--delayed-sources become non-empty during startup, if none of the
files loaded during startup need to be native-compiled.

> Unless I'm wrong the problem I see here is that if
> `comp--delayed-sources' is empty we never set `comp--loadable' to t.

Yes, I think so.

> I'll be testing a patch today and report.

Thanks.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Arash Esbati <arash@gnu.org>, larsi@gnus.org, 53497@debbugs.gnu.org
>> Date: Thu, 27 Jan 2022 10:11:29 +0000
>> 
>> Before `comp--loadable' becomes true (read the native compiler is not
>> loadable) each time we enter in 'maybe_defer_native_compilation' we
>> accumulate the compilation units we want to compile in
>> `comp--delayed-sources'.
>> 
>> When we finally call `startup--honor-delayed-native-compilations' we
>> check if something is pending in `comp--delayed-sources' and if this is
>> the case we load the native compiler and we compile what's pending.
>
> Yes, I understood that much.  What I didn't understand was how would
> comp--delayed-sources become non-empty during startup, if none of the
> files loaded during startup need to be native-compiled.
>
>> Unless I'm wrong the problem I see here is that if
>> `comp--delayed-sources' is empty we never set `comp--loadable' to t.
>
> Yes, I think so.
>
>> I'll be testing a patch today and report.
>
> Thanks.

Hi Eli,

I pushed d0aac84b2a as it seems to work for me here.

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: arash@gnu.org, larsi@gnus.org, 53497@debbugs.gnu.org
> Date: Thu, 27 Jan 2022 10:57:19 +0000
> 
> I pushed d0aac84b2a as it seems to work for me here.

Thanks.  But is it right to set comp--loadable regardless of whether
native-comp-available-p returns non-nil?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: arash@gnu.org, larsi@gnus.org, 53497@debbugs.gnu.org
>> Date: Thu, 27 Jan 2022 10:57:19 +0000
>> 
>> I pushed d0aac84b2a as it seems to work for me here.
>
> Thanks.  But is it right to set comp--loadable regardless of whether
> native-comp-available-p returns non-nil?

In principle I'd say so, otherwhise we'll keep accumulating filenames in
`comp--delayed-sources' for all the session.

If we don't want to have errors raised by the deferred compilation when
an Emacs with native comp support is running without the native compiler
available I think we should guard against `native-comp-available-p'
inside 'maybe_defer_native_compilation'.  WDYT?

Thanks

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Hi Andrea,

Andrea Corallo <akrl@sdf.org> writes:

> I pushed d0aac84b2a as it seems to work for me here.

Thanks for looking into this.  I built Emacs (0991e8686cd) and started
with "-Q".  Doing C-x C-f trying to open a .tex file says:

  require: Recursive ‘require’ for feature ‘comp’

in the minibuffer and the file doesn't get loaded.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Thu, 27 Jan 2022 16:03:40 +0100
> 
> > I pushed d0aac84b2a as it seems to work for me here.
> 
> Thanks for looking into this.  I built Emacs (0991e8686cd) and started
> with "-Q".  Doing C-x C-f trying to open a .tex file says:
> 
>   require: Recursive ‘require’ for feature ‘comp’
> 
> in the minibuffer and the file doesn't get loaded.

Please run Emacs under GDB, put a breakpoint in Frequire, here:

      if (nesting > 3)
	error ("Recursive `require' for feature `%s'",  <<<<<<<<<<<<<<<<<<
	       SDATA (SYMBOL_NAME (feature)));

repeat the above sequence, and when the breakpoint breaks, show the
backtrace and xbacktrace.  (For "xbacktrace" you will need to "source
.gdbinit", as you did before.)

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Please run Emacs under GDB, put a breakpoint in Frequire, here:
>
>       if (nesting > 3)
> 	error ("Recursive `require' for feature `%s'",  <<<<<<<<<<<<<<<<<<
> 	       SDATA (SYMBOL_NAME (feature)));
>
> repeat the above sequence, and when the breakpoint breaks, show the
> backtrace and xbacktrace.  (For "xbacktrace" you will need to "source
> .gdbinit", as you did before.)

Please find attached the results.  Took me some iterations in GDB to get
to the error.

As a note, I started the session directly in emacs/src tree with
'gdb ./emacs'.  But that shouldn't make a difference, I can trigger the
error also from an installed version with 'make install'.

Best, Arash

[-- Attachment #2: backtrace --]
[-- Type: application/octet-stream, Size: 20873 bytes --]

3244          if (nesting > 3)
(gdb) n
3245            error ("Recursive `require' for feature `%s'",
(gdb) backtrace
#0  Frequire (feature=XIL(0x4320), filename=XIL(0), noerror=XIL(0)) at fns.c:3245
#1  0x00007ff6237f1fd5 in maybe_defer_native_compilation (
    function_name=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec0358f35)) at comp.c:5131
#2  0x00007ff62376dc93 in Fdefalias (symbol=XIL(0xffff82489ddecdf0),
    definition=XIL(0x23ec0358f35), docstring=XIL(0)) at data.c:909
#3  0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1a48aa3)) at eval.c:2530
#4  0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7ee920,
    sourcename=XIL(0x23ec12bcd94), printflag=false, unibyte=XIL(0), readfun=XIL(0),
    start=XIL(0), end=XIL(0)) at lread.c:2336
#5  0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0),
    nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#6  0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec05077ac),
    noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at lread.c:1638
#7  0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489c7f07f8), filename=XIL(0),
    noerror=XIL(0)) at fns.c:3257
#8  0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1,
    args=0x6baf7eec48) at eval.c:3142
#9  0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1329f54),
    vector=XIL(0x23ec1a36935), maxdepth=make_fixnum(2), args_template=0, nargs=0,
    args=0x0) at bytecode.c:676
#10 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1329f54),
    vector=XIL(0x23ec1a36935), maxdepth=make_fixnum(2)) at bytecode.c:336
#11 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1386c53)) at eval.c:2530
#12 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7ef840,
    sourcename=XIL(0x23ec13346d4), printflag=false, unibyte=XIL(0), readfun=XIL(0),
    start=XIL(0), end=XIL(0)) at lread.c:2336
#13 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec1b7fb04), noerror=XIL(0),
    nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#14 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec1b7fb04),
    noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at lread.c:1638
#15 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489de68f10), filename=XIL(0),
    noerror=XIL(0)) at fns.c:3257
#16 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1,
    args=0x6baf7efb68) at eval.c:3142
#17 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1b7fae4),
    vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10), args_template=0, nargs=0,
    args=0x0) at bytecode.c:676
#18 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1b7fae4),
    vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10)) at bytecode.c:336
#19 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b78453)) at eval.c:2530
#20 0x00007ff62378eaec in Feval (form=XIL(0x23ec1b78453), lexical=XIL(0x30))
    at eval.c:2349
#21 0x00007ffd2bce3498 in top_level_run (par_0=0x23ec1b24675)
   from z:\path\to\emacs\native-lisp\29.0.50-44df2309\comp-7672a6ed-46efb6d0.eln
#22 0x00007ff6237f2a2d in load_comp_unit (comp_u=0x23ec1b24670, loading_dump=false,
    late_load=false) at comp.c:5362
#23 0x00007ff6237f3505 in Fnative_elisp_load (filename=XIL(0x23ec1384454),
    late_load=XIL(0)) at comp.c:5586
#24 0x00007ff6237c5bea in Fload (file=XIL(0x23ec0646d3c), noerror=XIL(0),
    nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1574
#25 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec0646d3c),
    noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at lread.c:1638
#26 0x00007ff6237a02c4 in Frequire (feature=XIL(0x4320), filename=XIL(0),
    noerror=XIL(0)) at fns.c:3257
#27 0x00007ff6237f1fd5 in maybe_defer_native_compilation (
    function_name=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec0347715)) at comp.c:5131
#28 0x00007ff62376dc93 in Fdefalias (symbol=XIL(0xffff82489ddecdf0),
    definition=XIL(0x23ec0347715), docstring=XIL(0)) at data.c:909
#29 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec13885b3)) at eval.c:2530
#30 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f1390,
    sourcename=XIL(0x23ec19c58d4), printflag=false, unibyte=XIL(0), readfun=XIL(0),
    start=XIL(0), end=XIL(0)) at lread.c:2336
#31 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0),
    nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#32 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec05077ac),
    noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at lread.c:1638
#33 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489c7f07f8), filename=XIL(0),
    noerror=XIL(0)) at fns.c:3257
#34 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1,
    args=0x6baf7f16b8) at eval.c:3142
#35 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec12fa0c4),
    vector=XIL(0x23ec19e15b5), maxdepth=make_fixnum(2), args_template=0, nargs=0,
    args=0x0) at bytecode.c:676
#36 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec12fa0c4),
    vector=XIL(0x23ec19e15b5), maxdepth=make_fixnum(2)) at bytecode.c:336
#37 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b172c3)) at eval.c:2530
#38 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f22b0,
    sourcename=XIL(0x23ec12e2214), printflag=false, unibyte=XIL(0), readfun=XIL(0),
    start=XIL(0), end=XIL(0)) at lread.c:2336
#39 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec1b7fb04), noerror=XIL(0),
--Type <RET> for more, q to quit, c to continue without paging--c
    nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#40 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec1b7fb04), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#41 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489de68f10), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#42 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1, args=0x6baf7f25d8) at eval.c:3142
#43 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10), args_template=0, nargs=0, args=0x0) at bytecode.c:676
#44 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10)) at bytecode.c:336
#45 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b78453)) at eval.c:2530
#46 0x00007ff62378eaec in Feval (form=XIL(0x23ec1b78453), lexical=XIL(0x30)) at eval.c:2349
#47 0x00007ffd2bce3498 in top_level_run (par_0=0x23ec1b24675) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\comp-7672a6ed-46efb6d0.eln
#48 0x00007ff6237f2a2d in load_comp_unit (comp_u=0x23ec1b24670, loading_dump=false, late_load=false) at comp.c:5362
#49 0x00007ff6237f3505 in Fnative_elisp_load (filename=XIL(0x23ec14045b4), late_load=XIL(0)) at comp.c:5586
#50 0x00007ff6237c5bea in Fload (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1574
#51 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#52 0x00007ff6237a02c4 in Frequire (feature=XIL(0x4320), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#53 0x00007ff6237f1fd5 in maybe_defer_native_compilation (function_name=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec19e1555)) at comp.c:5131
#54 0x00007ff62376dc93 in Fdefalias (symbol=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec19e1555), docstring=XIL(0)) at data.c:909
#55 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b175e3)) at eval.c:2530
#56 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f3e00, sourcename=XIL(0x23ec13c2844), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0),
 end=XIL(0)) at lread.c:2336
#57 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#58 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec05077ac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#59 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489c7f07f8), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#60 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1, args=0x6baf7f4128) at eval.c:3142
#61 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1395c44), vector=XIL(0x23ec033f915), maxdepth=make_fixnum(2), args_template=0, nargs=0, args=0x0) at bytecode.c:676
#62 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1395c44), vector=XIL(0x23ec033f915), maxdepth=make_fixnum(2)) at bytecode.c:336
#63 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b17ea3)) at eval.c:2530
#64 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f4d20, sourcename=XIL(0x23ec1b0a854), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0),
 end=XIL(0)) at lread.c:2336
#65 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec1b7fb04), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#66 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec1b7fb04), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#67 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489de68f10), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#68 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1, args=0x6baf7f5048) at eval.c:3142
#69 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10), args_template=0, nargs=0, args=0x0) at bytecode.c:676
#70 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10)) at bytecode.c:336
#71 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b78453)) at eval.c:2530
#72 0x00007ff62378eaec in Feval (form=XIL(0x23ec1b78453), lexical=XIL(0x30)) at eval.c:2349
#73 0x00007ffd2bce3498 in top_level_run (par_0=0x23ec1b24675) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\comp-7672a6ed-46efb6d0.eln
#74 0x00007ff6237f2a2d in load_comp_unit (comp_u=0x23ec1b24670, loading_dump=false, late_load=false) at comp.c:5362
#75 0x00007ff6237f3505 in Fnative_elisp_load (filename=XIL(0x23ec1b28ce4), late_load=XIL(0)) at comp.c:5586
#76 0x00007ff6237c5bea in Fload (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1574
#77 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#78 0x00007ff6237a02c4 in Frequire (feature=XIL(0x4320), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#79 0x00007ff6237f1fd5 in maybe_defer_native_compilation (function_name=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec1399e15)) at comp.c:5131
#80 0x00007ff62376dc93 in Fdefalias (symbol=XIL(0xffff82489ddecdf0), definition=XIL(0x23ec1399e15), docstring=XIL(0)) at data.c:909
#81 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b04943)) at eval.c:2530
#82 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f6870, sourcename=XIL(0x23ec1c03de4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0),
 end=XIL(0)) at lread.c:2336
#83 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#84 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec05077ac), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#85 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489c7f07f8), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#86 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1, args=0x6baf7f6b98) at eval.c:3142
#87 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1b290a4), vector=XIL(0x23ec1b0bb65), maxdepth=make_fixnum(2), args_template=0, nargs=0, args=0x0) at bytecode.c:676
#88 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1b290a4), vector=XIL(0x23ec1b0bb65), maxdepth=make_fixnum(2)) at bytecode.c:336
#89 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b055e3)) at eval.c:2530
#90 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f7790, sourcename=XIL(0x23ec1384b74), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0),
 end=XIL(0)) at lread.c:2336
#91 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec1b7fb04), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#92 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec1b7fb04), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#93 0x00007ff6237a02c4 in Frequire (feature=XIL(0xffff82489de68f10), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#94 0x00007ff623790faf in funcall_subr (subr=0x7ff623c3c040 <Srequire>, numargs=1, args=0x6baf7f7ab8) at eval.c:3142
#95 0x00007ff6237e07e0 in exec_byte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10), args_template=0, nargs=0, args=0x0) at bytecode.c:676
#96 0x00007ff6237dfb40 in Fbyte_code (bytestr=XIL(0x23ec1b7fae4), vector=XIL(0x23ec1b9bcf5), maxdepth=make_fixnum(10)) at bytecode.c:336
#97 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b78453)) at eval.c:2530
#98 0x00007ff62378eaec in Feval (form=XIL(0x23ec1b78453), lexical=XIL(0x30)) at eval.c:2349
#99 0x00007ffd2bce3498 in top_level_run (par_0=0x23ec1b24675) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\comp-7672a6ed-46efb6d0.eln
#100 0x00007ff6237f2a2d in load_comp_unit (comp_u=0x23ec1b24670, loading_dump=false, late_load=false) at comp.c:5362
#101 0x00007ff6237f3505 in Fnative_elisp_load (filename=XIL(0x23ec1b33914), late_load=XIL(0)) at comp.c:5586
#102 0x00007ff6237c5bea in Fload (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1574
#103 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec0646d3c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#104 0x00007ff6237a02c4 in Frequire (feature=XIL(0x4320), filename=XIL(0), noerror=XIL(0)) at fns.c:3257
#105 0x00007ff6237f1fd5 in maybe_defer_native_compilation (function_name=XIL(0xffff82489c90a178), definition=XIL(0x23ec1b20a85)) at comp.c:5131
#106 0x00007ff62376dc93 in Fdefalias (symbol=XIL(0xffff82489c90a178), definition=XIL(0x23ec1b20a85), docstring=XIL(0)) at data.c:909
#107 0x00007ff62378f528 in eval_sub (form=XIL(0x23ec1b2d753)) at eval.c:2530
#108 0x00007ff6237c8198 in readevalloop (readcharfun=XIL(0x7650), infile0=0x6baf7f92e0, sourcename=XIL(0x23ec1b28d84), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2336
#109 0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec062115c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
#110 0x00007ff6237c5f6b in save_match_data_load (file=XIL(0x23ec062115c), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1638
#111 0x00007ff62378e970 in Fautoload_do_load (fundef=XIL(0x23ec065711b), funname=XIL(0xffff82489c940168), macro_only=XIL(0)) at eval.c:2317
#112 0x00007ff623790bb0 in funcall_general (fun=XIL(0x23ec065711b), numargs=1, args=0x6baf7f9578) at eval.c:3050
#113 0x00007ff623790cfb in Ffuncall (nargs=2, args=0x6baf7f9570) at eval.c:3085
#114 0x00007ff623790488 in call1 (fn=XIL(0xffff82489c940168), arg1=XIL(0x23ec1b14553)) at eval.c:2922
#115 0x00007ff62368f4ca in Ffind_operation_coding_system (nargs=6, args=0x6baf7f9670) at coding.c:10817
#116 0x00007ff623723911 in Finsert_file_contents (filename=XIL(0x23ec13c73b4), visit=XIL(0x30), beg=XIL(0), end=XIL(0), replace=XIL(0)) at fileio.c:4726
#117 0x00007ff62379103b in funcall_subr (subr=0x7ff623c31ea0 <Sinsert_file_contents>, numargs=2, args=0x6baf7fdfd0) at eval.c:3149
#118 0x00007ff623790a47 in funcall_general (fun=XIL(0x7ff623c31ea5), numargs=2, args=0x6baf7fdfd0) at eval.c:3031
#119 0x00007ff623790cfb in Ffuncall (nargs=3, args=0x6baf7fdfc8) at eval.c:3085
#120 0x00007ffd6194a446 in F66696e642d66696c652d6e6f73656c6563742d31_find_file_noselect_1_0 (par_0=<optimized out>, par_1=<optimized out>, par_2=<optimized out>, par_3=<optimized out>, par_4=0x23ec12b8404, par_5=0x23ec1b14fa3) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\preloaded\files-1e8937b2-8ae7d5e2.eln
#121 0x00007ff623791099 in funcall_subr (subr=0x23ec09be648, numargs=6, args=0x6baf7fe1d0) at eval.c:3153
#122 0x00007ff623790a47 in funcall_general (fun=XIL(0x23ec09be64d), numargs=6, args=0x6baf7fe1d0) at eval.c:3031
#123 0x00007ff623790cfb in Ffuncall (nargs=7, args=0x6baf7fe1c8) at eval.c:3085
#124 0x00007ffd619490ba in F66696e642d66696c652d6e6f73656c656374_find_file_noselect_0 (par_0=<optimized out>, par_1=<optimized out>, par_2=<optimized out>, par_3=<optimized out>) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\preloaded\files-1e8937b2-8ae7d5e2.eln
#125 0x00007ff623790ff0 in funcall_subr (subr=0x23ec053ecd0, numargs=4, args=0x6baf7fe3a8) at eval.c:3145
#126 0x00007ff623790a47 in funcall_general (fun=XIL(0x23ec053ecd5), numargs=4, args=0x6baf7fe3a8) at eval.c:3031
#127 0x00007ff623790cfb in Ffuncall (nargs=5, args=0x6baf7fe3a0) at eval.c:3085
#128 0x00007ffd61946bb6 in F66696e642d66696c65_find_file_0 (par_0=<optimized out>, par_1=<optimized out>) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\preloaded\files-1e8937b2-8ae7d5e2.eln
#129 0x00007ff623790f7c in funcall_subr (subr=0x23ec04b3e10, numargs=2, args=0x6baf7fe6e0) at eval.c:3139
#130 0x00007ff623790a47 in funcall_general (fun=XIL(0x23ec04b3e15), numargs=2, args=0x6baf7fe6e0) at eval.c:3031
#131 0x00007ff623790cfb in Ffuncall (nargs=3, args=0x6baf7fe6d8) at eval.c:3085
#132 0x00007ff6237868f8 in Ffuncall_interactively (nargs=3, args=0x6baf7fe6d8) at callint.c:260
#133 0x00007ff623790e86 in funcall_subr (subr=0x7ff623c38c20 <Sfuncall_interactively>, numargs=3, args=0x6baf7fe6d8) at eval.c:3117
#134 0x00007ff623790a47 in funcall_general (fun=XIL(0x7ff623c38c25), numargs=3, args=0x6baf7fe6d8) at eval.c:3031
#135 0x00007ff623790cfb in Ffuncall (nargs=4, args=0x6baf7fe6d0) at eval.c:3085
#136 0x00007ff62378fe9f in Fapply (nargs=3, args=0x6baf7fe7a0) at eval.c:2692
#137 0x00007ff623786cef in Fcall_interactively (function=XIL(0xffff82489c79cbe0), record_flag=XIL(0), keys=XIL(0x23ec0d1b0c5)) at callint.c:353
#138 0x00007ffd6156c2bf in F636f6d6d616e642d65786563757465_command_execute_0 (par_0=0xffff82489c79cbe0, par_1=0x0, par_2=0x0, par_3=<optimized out>) from z:\path\to\emacs\native-lisp\29.0.50-44df2309\preloaded\simple-fab5b0cf-23b57aaa.eln
#139 0x00007ff623790ff0 in funcall_subr (subr=0x23ec0587ed0, numargs=1, args=0x6baf7fec18) at eval.c:3145
#140 0x00007ff623790a47 in funcall_general (fun=XIL(0x23ec0587ed5), numargs=1, args=0x6baf7fec18) at eval.c:3031
#141 0x00007ff623790cfb in Ffuncall (nargs=2, args=0x6baf7fec10) at eval.c:3085
#142 0x00007ff623790488 in call1 (fn=XIL(0x4230), arg1=XIL(0xffff82489c79cbe0)) at eval.c:2922
#143 0x00007ff6236cf4b4 in command_loop_1 () at keyboard.c:1509
#144 0x00007ff62378ccaa in internal_condition_case (bfun=0x7ff6236ceb5f <command_loop_1>, handlers=XIL(0x90), hfun=0x7ff6236ce013 <cmd_error>) at eval.c:1485
#145 0x00007ff6236ce7bd in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1137
#146 0x00007ff62378c3a5 in internal_catch (tag=XIL(0xf8d0), func=0x7ff6236ce794 <command_loop_2>, arg=XIL(0x90)) at eval.c:1216
#147 0x00007ff6236ce716 in command_loop () at keyboard.c:1115
#148 0x00007ff6236cdb8c in recursive_edit_1 () at keyboard.c:724
#149 0x00007ff6236cdd4b in Frecursive_edit () at keyboard.c:807
#150 0x00007ff6236ca032 in main (argc=2, argv=0x23ebeaf4c20) at emacs.c:2427

Lisp Backtrace:
"defalias" (0xaf7ee210)
"require" (0xaf7eec48)
"byte-code" (0xaf7ef130)
"require" (0xaf7efb68)
"byte-code" (0xaf7f0090)
"defalias" (0xaf7f0c80)
"require" (0xaf7f16b8)
"byte-code" (0xaf7f1ba0)
"require" (0xaf7f25d8)
"byte-code" (0xaf7f2b00)
"defalias" (0xaf7f36f0)
"require" (0xaf7f4128)
"byte-code" (0xaf7f4610)
"require" (0xaf7f5048)
"byte-code" (0xaf7f5570)
"defalias" (0xaf7f6160)
"require" (0xaf7f6b98)
"byte-code" (0xaf7f7080)
"require" (0xaf7f7ab8)
"byte-code" (0xaf7f7fe0)
"defalias" (0xaf7f8bd0)
"latexenc-find-file-coding-system" (0xaf7f9578)
"insert-file-contents" (0xaf7fdfd0)
"find-file-noselect-1" (0xaf7fe1d0)
"find-file-noselect" (0xaf7fe3a8)
"find-file" (0xaf7fe6e0)
"funcall-interactively" (0xaf7fe6d8)
"command-execute" (0xaf7fec18)

[-- Attachment #3: xbacktrace --]
[-- Type: application/octet-stream, Size: 768 bytes --]

(gdb) xbacktrace
"defalias" (0xaf7ee210)
"require" (0xaf7eec48)
"byte-code" (0xaf7ef130)
"require" (0xaf7efb68)
"byte-code" (0xaf7f0090)
"defalias" (0xaf7f0c80)
"require" (0xaf7f16b8)
"byte-code" (0xaf7f1ba0)
"require" (0xaf7f25d8)
"byte-code" (0xaf7f2b00)
"defalias" (0xaf7f36f0)
"require" (0xaf7f4128)
"byte-code" (0xaf7f4610)
"require" (0xaf7f5048)
"byte-code" (0xaf7f5570)
"defalias" (0xaf7f6160)
"require" (0xaf7f6b98)
"byte-code" (0xaf7f7080)
"require" (0xaf7f7ab8)
"byte-code" (0xaf7f7fe0)
"defalias" (0xaf7f8bd0)
"latexenc-find-file-coding-system" (0xaf7f9578)
"insert-file-contents" (0xaf7fdfd0)
"find-file-noselect-1" (0xaf7fe1d0)
"find-file-noselect" (0xaf7fe3a8)
"find-file" (0xaf7fe6e0)
"funcall-interactively" (0xaf7fe6d8)
"command-execute" (0xaf7fec18)

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Arash Esbati <arash@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Please run Emacs under GDB, put a breakpoint in Frequire, here:
>>
>>       if (nesting > 3)
>> 	error ("Recursive `require' for feature `%s'",  <<<<<<<<<<<<<<<<<<
>> 	       SDATA (SYMBOL_NAME (feature)));
>>
>> repeat the above sequence, and when the breakpoint breaks, show the
>> backtrace and xbacktrace.  (For "xbacktrace" you will need to "source
>> .gdbinit", as you did before.)
>
> Please find attached the results.  Took me some iterations in GDB to get
> to the error.

Hi Arash,

apologies for not having time to re-read the whole thread.  What's the
current minimal reproducer we have to obtain this?

Thanks!

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, 53497@debbugs.gnu.org
> Date: Thu, 27 Jan 2022 16:37:07 +0000
> 
> apologies for not having time to re-read the whole thread.  What's the
> current minimal reproducer we have to obtain this?

Like he said:

> I built Emacs (0991e8686cd) and started with "-Q".  Doing C-x C-f
> trying to open a .tex file says:
> 
>   require: Recursive ‘require’ for feature ‘comp’

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, 53497@debbugs.gnu.org
>> Date: Thu, 27 Jan 2022 16:37:07 +0000
>> 
>> apologies for not having time to re-read the whole thread.  What's the
>> current minimal reproducer we have to obtain this?
>
> Like he said:
>
>> I built Emacs (0991e8686cd) and started with "-Q".  Doing C-x C-f
>> trying to open a .tex file says:
>> 
>>   require: Recursive ‘require’ for feature ‘comp’

Thanks, I think I see what's going on.  I've an (hopefully) better
patch, I'll test it better after dinner and report.

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <akrl@sdf.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, 53497@debbugs.gnu.org
>>> Date: Thu, 27 Jan 2022 16:37:07 +0000
>>> 
>>> apologies for not having time to re-read the whole thread.  What's the
>>> current minimal reproducer we have to obtain this?
>>
>> Like he said:
>>
>>> I built Emacs (0991e8686cd) and started with "-Q".  Doing C-x C-f
>>> trying to open a .tex file says:
>>> 
>>>   require: Recursive ‘require’ for feature ‘comp’
>
> Thanks, I think I see what's going on.  I've an (hopefully) better
> patch, I'll test it better after dinner and report.
>
>   Andrea

So I could not reproduce the issue (probably because of a different
configuration), but I think (hope) 536a57b72c might help with the
problem.

Arash could you test if it works for you?

Thanks for your time.

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Andrea Corallo <akrl@sdf.org> writes:

> So I could not reproduce the issue (probably because of a different
> configuration),

I'm curious: Am I the only user having this issue?

> but I think (hope) 536a57b72c might help with the problem.
>
> Arash could you test if it works for you?

I did with version 84d4a34919.  I built Emacs as described here[1] and
this is how it works:

1. emacs -Q

I start with "emacs -Q" and "C-x C-f" a .tex file.  Emacs opens the file
and native-compiles:

Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/subr-x.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/gv.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-extra.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/help-mode.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-macs.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/rx.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/warnings.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/international/latexenc.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/ring.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/ansi-color.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/comint.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/pcomplete.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/shell.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/text-property-search.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/compile.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/textmodes/tex-mode.el...
Compilation finished.

I close Emacs, re-start with "emacs -Q" and it does:

Compilation finished.
Compiling d:/arash/Dev/Emacs/emacs-install-native-comp/share/emacs/29.0.50/lisp/calendar/time-date.el...
Compilation finished.

No further native-compiling after further re-starts.

2. emacs &

Emacs native-compiles a series of files upon start, I skipped opening my
.tex file and re-started Emacs, and it native-compiles the files again,
and this cycle goes on and on.  I'm attaching the results further below.

So I think there is still something going wrong.  My .emacs is actually
not complicated and the only `native-compile' relevant bit is:

    (when (featurep 'native-compile)
      (setq native-comp-async-report-warnings-errors 'silent))

> Thanks for your time.

Sure, thanks to you and Eli for yours.

Best, Arash

Footnotes:
[1]  https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-01/msg01877.html


a) Result after the first start with "emacs &"

Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/subr-x.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/gv.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-vars.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/map.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/json.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/password-cache.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio-core.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-macs.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/auth-source.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-parse.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-handlers.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/mailcap.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-util.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-domsuf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-cookie.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-history.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-methods.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-expand.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-privacy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-proxy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/browse-url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/package.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/info.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/server.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tab-line.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/delsel.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/elec-pair.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/wid-edit.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tree-widget.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/recentf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tempo.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/cal-menu.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/calendar.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/time.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/diary-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/appt.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/timezone.el...
Compiling z:/myhome/.emacs.d/elpa/bbdb-20210108.38/bbdb.el...

In toplevel form:
bbdb.el:1351:2: Warning: custom-declare-variable `bbdb-mua-summary-unification-list' docstring wider than 80 characters
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/pcase.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-bbdb.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-template.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-semantic.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-cmake.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-capf.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-clang.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-files.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev-code.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-gtags.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/ring.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/project.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/xref.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/generator.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/fileloop.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-keywords.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-oddmuse.el...
Compiling z:/myhome/.emacs.d/elpa/aggressive-indent-20210701.2224/aggressive-indent.el...

In toplevel form:
aggressive-indent.el:491:2: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode'
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/easy-mmode.el...

In aggressive-indent-mode:
aggressive-indent.el:504:16: Warning: reference to free variable `global-aggressive-indent-mode'
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-extra.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/help-mode.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/rx.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/warnings.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/time-date.el...
Compilation finished.

b) Result after the second start:

Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/subr-x.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/gv.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-vars.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/json.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/map.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/password-cache.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio-core.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-macs.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/auth-source.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-parse.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-handlers.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/mailcap.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-util.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-domsuf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-cookie.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-history.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-methods.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-expand.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-privacy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-proxy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/browse-url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/package.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/info.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/server.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tab-line.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/delsel.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/elec-pair.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/wid-edit.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tree-widget.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/recentf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tempo.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/cal-menu.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/calendar.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/time.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/diary-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/appt.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/timezone.el...
Compiling z:/myhome/.emacs.d/elpa/bbdb-20210108.38/bbdb.el...

In toplevel form:
bbdb.el:1351:2: Warning: custom-declare-variable `bbdb-mua-summary-unification-list' docstring wider than 80 characters
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/pcase.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-bbdb.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-template.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-semantic.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-cmake.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-capf.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-clang.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-files.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev-code.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-gtags.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/ring.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/project.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/xref.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/generator.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/fileloop.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-keywords.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-oddmuse.el...
Compiling z:/myhome/.emacs.d/elpa/aggressive-indent-20210701.2224/aggressive-indent.el...

In toplevel form:
aggressive-indent.el:491:2: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode'
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/easy-mmode.el...

In aggressive-indent-mode:
aggressive-indent.el:504:16: Warning: reference to free variable `global-aggressive-indent-mode'
Compilation finished.

c) Result after the third start:

Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/gv.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/subr-x.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-vars.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/map.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/json.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/password-cache.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio-core.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-macs.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/auth-source.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-parse.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-handlers.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/mailcap.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-util.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-domsuf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-cookie.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-history.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-methods.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-expand.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-privacy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-proxy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/browse-url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/package.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/info.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/server.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tab-line.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/delsel.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/elec-pair.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/wid-edit.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tree-widget.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/recentf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tempo.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/cal-menu.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/calendar.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/time.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/diary-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/timezone.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/appt.el...
Compiling z:/myhome/.emacs.d/elpa/bbdb-20210108.38/bbdb.el...

In toplevel form:
bbdb.el:1351:2: Warning: custom-declare-variable `bbdb-mua-summary-unification-list' docstring wider than 80 characters
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/pcase.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-bbdb.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-template.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-semantic.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-cmake.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-capf.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-clang.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-files.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev-code.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-gtags.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/ring.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/project.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/xref.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/generator.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/fileloop.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-keywords.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-oddmuse.el...
Compiling z:/myhome/.emacs.d/elpa/aggressive-indent-20210701.2224/aggressive-indent.el...

In toplevel form:
aggressive-indent.el:491:2: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode'

In aggressive-indent-mode:
aggressive-indent.el:504:16: Warning: reference to free variable `global-aggressive-indent-mode'
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/easy-mmode.el...
Compilation finished.

d) Result after the fourth start:

Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/gv.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/subr-x.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-vars.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/json.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/map.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/password-cache.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/eieio-core.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-macs.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/auth-source.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/cl-seq.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-parse.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-handlers.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/mailcap.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-util.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-domsuf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-cookie.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-history.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-methods.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-expand.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-privacy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/url/url-proxy.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/net/browse-url.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/package.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/info.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/server.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tab-line.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/delsel.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/elec-pair.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/wid-edit.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tree-widget.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/recentf.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/tempo.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/cal-menu.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/calendar.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/time.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/diary-lib.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/calendar/appt.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/timezone.el...
Compiling z:/myhome/.emacs.d/elpa/bbdb-20210108.38/bbdb.el...

In toplevel form:
bbdb.el:1351:2: Warning: custom-declare-variable `bbdb-mua-summary-unification-list' docstring wider than 80 characters
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/pcase.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-bbdb.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-template.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-semantic.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-cmake.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-capf.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-clang.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-files.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-dabbrev-code.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-gtags.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/ring.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/project.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/xref.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/generator.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/fileloop.el...
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/progmodes/etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-etags.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-keywords.el...
Compiling z:/myhome/.emacs.d/elpa/company-20220110.2248/company-oddmuse.el...
Compiling z:/myhome/.emacs.d/elpa/aggressive-indent-20210701.2224/aggressive-indent.el...

In toplevel form:
aggressive-indent.el:491:2: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode'

In aggressive-indent-mode:
aggressive-indent.el:504:16: Warning: reference to free variable `global-aggressive-indent-mode'
Compiling z:/pathto/emacs/share/emacs/29.0.50/lisp/emacs-lisp/easy-mmode.el...
Compilation finished.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  53497@debbugs.gnu.org,  larsi@gnus.org
> Date: Fri, 28 Jan 2022 10:24:01 +0100
> 
> Emacs native-compiles a series of files upon start, I skipped opening my
> .tex file and re-started Emacs, and it native-compiles the files again,
> and this cycle goes on and on.  I'm attaching the results further below.

Andrea, I see something similar as well in "emacs -Q -nw" on
GNU/Linux: subr-x.el and gv.el are natively-compiled each time I
restart Emacs, even though the previously-compiled *.eln files with
exactly the same 2 hashes in their names are already present in the
~/.emacs.d/eln-cache/.  Don't you see this on your system?  Perhaps
the -nw switch is needed to trigger this, but other than that, I need
nothing to reproduce the problem.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  53497@debbugs.gnu.org,  larsi@gnus.org
>> Date: Fri, 28 Jan 2022 10:24:01 +0100
>> 
>> Emacs native-compiles a series of files upon start, I skipped opening my
>> .tex file and re-started Emacs, and it native-compiles the files again,
>> and this cycle goes on and on.  I'm attaching the results further below.
>
> Andrea, I see something similar as well in "emacs -Q -nw" on
> GNU/Linux: subr-x.el and gv.el are natively-compiled each time I
> restart Emacs, even though the previously-compiled *.eln files with
> exactly the same 2 hashes in their names are already present in the
> ~/.emacs.d/eln-cache/.  Don't you see this on your system?  Perhaps
> the -nw switch is needed to trigger this, but other than that, I need
> nothing to reproduce the problem.

I can see it now with "emacs -Q -nw" thanks, I'll look into that.

BR

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Arash Esbati <arash@gnu.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  53497@debbugs.gnu.org,  larsi@gnus.org
>>> Date: Fri, 28 Jan 2022 10:24:01 +0100
>>>
>>> Emacs native-compiles a series of files upon start, I skipped opening my
>>> .tex file and re-started Emacs, and it native-compiles the files again,
>>> and this cycle goes on and on.  I'm attaching the results further below.
>>
>> Andrea, I see something similar as well in "emacs -Q -nw" on
>> GNU/Linux: subr-x.el and gv.el are natively-compiled each time I
>> restart Emacs, even though the previously-compiled *.eln files with
>> exactly the same 2 hashes in their names are already present in the
>> ~/.emacs.d/eln-cache/.  Don't you see this on your system?  Perhaps
>> the -nw switch is needed to trigger this, but other than that, I need
>> nothing to reproduce the problem.
>
> I can see it now with "emacs -Q -nw" thanks, I'll look into that.
>
> BR
>
>   Andrea

Okay, I think this is an unrelated issue to the circular dependency one
(that appears to be solved).

I see that when subr-x is required (see following stacktrace)...

"require" (0xffff9ef8)
"byte-code" (0xffffa3e0)
"byte-compile-eval" (0xffffa678)
0xc53bd8 PVEC_COMPILED
"byte-compile-recurse-toplevel" (0xffffad88)
0xb6da60 PVEC_COMPILED
"macroexpand" (0xffffb5a8)
"macroexp-macroexpand" (0xffffb828)
"macroexp--expand-all" (0xffffbbb8)
"macroexp--all-forms" (0xffffbe28)
"macroexp--expand-all" (0xffffc148)
"macroexpand-all" (0xffffc2a8)
"byte-compile-preprocess" (0xffffc428)
0xb82c50 PVEC_SUBR
"byte-compile" (0xffffc7d8)
"cl--generic-get-dispatcher" (0xffffc9a8)
"cl--generic-make-next-function" (0xffffcb28)
"cl--generic-make-function" (0xffffcd18)
"cl-generic-define-method" (0xffffcec8)
"byte-code" (0xffffd3d0)
0xf4b5d448 PVEC_SUBR
"tty-find-type" (0xffffdb28)
"tty-run-terminal-initialization" (0xffffdcd8)
"command-line" (0xffffde90)
"normal-top-level" (0xffffdf20)

...we do not find the coprresponding .eln even if present because
'Vnative_comp_eln_load_path' has still to be updated with the eln-cache
directory of the user.  In my case the content there is only:

("/home/akrl/emacs2/src/../native-lisp/")

Given the .eln is not found we native compile it again.

I suspect this is related to the recent changes of where
`native-comp-eln-load-path' is set, maybe Lars can comment.

Note that I'm on bf695b937e so I should have the very latest changes.

Best Regards

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> I suspect this is related to the recent changes of where
> `native-comp-eln-load-path' is set, maybe Lars can comment.

That's certainly possible -- it's really difficult to trace the logic
here in the startup code.

Does moving the setting earlier again fix the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> I suspect this is related to the recent changes of where
>> `native-comp-eln-load-path' is set, maybe Lars can comment.
>
> That's certainly possible -- it's really difficult to trace the logic
> here in the startup code.

Yeah our startup has a lot of hidden dependecies.

> Does moving the setting earlier again fix the problem?

If you refer to bf695b937e that's not sufficient, the test was done with
it installed.  I haven't checked if bf695b937e has restored the state of
say one week ago (in terms of where we set native-comp-eln-load-path) or
not.

But yeah the bottom line is that indeed we need to have
native-comp-eln-load-path set before we expect the native compiler
machinery to work.

Best Regards

  Andrea

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Arash Esbati <arash@gnu.org>,
>         53497@debbugs.gnu.org
> Date: Sat, 29 Jan 2022 07:40:37 +0000
> 
> >> I suspect this is related to the recent changes of where
> >> `native-comp-eln-load-path' is set, maybe Lars can comment.
> >
> > That's certainly possible -- it's really difficult to trace the logic
> > here in the startup code.
> 
> Yeah our startup has a lot of hidden dependecies.
> 
> > Does moving the setting earlier again fix the problem?
> 
> If you refer to bf695b937e that's not sufficient, the test was done with
> it installed.  I haven't checked if bf695b937e has restored the state of
> say one week ago (in terms of where we set native-comp-eln-load-path) or
> not.
> 
> But yeah the bottom line is that indeed we need to have
> native-comp-eln-load-path set before we expect the native compiler
> machinery to work.

I don't think we can move the initialization of
native-comp-eln-load-path to after the call to command-line, because
Lisp packages can be loaded as early as while loading early-init.el.
So we need to initialize native-comp-eln-load-path as soon as we have
user-emacs-directory, and then amend the value after calling
command-line.

I installed a fix along these lines which seems to be working for me.
Arash, please see if your problems are solved now.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> I installed a fix along these lines which seems to be working for me.
> Arash, please see if your problems are solved now.

Yes, they are solved now.  Many thanks to you all for taking your time!

I'll close this report.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Hi Andrea,

Andrea Corallo <akrl@sdf.org> writes:

> apologies for not having time to re-read the whole thread.  What's the
> current minimal reproducer we have to obtain this?

No problem.  I did:

- git pull (to 0991e8686c)
- git clean -fdx --exclude=ChangeLog
- ./autogen.sh
- ./configure --prefix=/z/emacs-install-native-comp \
              --with-native-compilation \
              --without-compress-install \
              --without-mailutils \
              --without-pop \
              CFLAGS='-O0 -g3
- make -j8 && make install
- cd /z/emacs-install-native-comp/bin
- ./emacs -Q
- In Emacs, C-x C-f path/to/minimal.tex (which is just an arbitatry
  minimal LaTeX file and attached)

To double check, I also started Emacs after compilation from src/ in the
git repo, same result.

This is on Win10 with gcc 11.2.0 (Msys2). Please let me know if I've
left out something important.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Thu, 27 Jan 2022 17:27:56 +0100
> 
> > repeat the above sequence, and when the breakpoint breaks, show the
> > backtrace and xbacktrace.  (For "xbacktrace" you will need to "source
> > .gdbinit", as you did before.)
> 
> Please find attached the results.  Took me some iterations in GDB to get
> to the error.
> 
> As a note, I started the session directly in emacs/src tree with
> 'gdb ./emacs'.  But that shouldn't make a difference, I can trigger the
> error also from an installed version with 'make install'.

Can you please go to each frame that shows a call to Fload, like this:

> #5  0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0),
>     nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588

and show the value of its 1st argument, called 'file'?  Like this:

 (gdb) fr 5
 (gdb) pp file

and similarly with every other frame that calls Fload, top to bottom?
The frame number is that #5 part that's at the beginning of each
backtrace line.

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you please go to each frame that shows a call to Fload, like this:
>
>> #5  0x00007ff6237c5cc1 in Fload (file=XIL(0x23ec05077ac), noerror=XIL(0),
>>     nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1588
>
> and show the value of its 1st argument, called 'file'?  Like this:
>
>  (gdb) fr 5
>  (gdb) pp file
>
> and similarly with every other frame that calls Fload, top to bottom?
> The frame number is that #5 part that's at the beginning of each
> backtrace line.

I built Emacs with the new patch provided by Andrea, see my other
message.  Please let me know if I can provide any input.

Best, Arash

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Why are you installing under a different prefix than used at configure
> time?

I usually have multiple Emacs versions on my HD.  I install the latest
build in a temp directory, test it there and then move the entire layout
over the old version with emacs/bin directory in my $PATH.  I don't
fiddle with the files installed by Emacs.

I thought this is a documented way to install Emacs?[1]

> What did you do after starting "emacs -Q"?  It isn't enough to start
> Emacs, you need to cause it to load some package before it will start
> compiling that package.

Sorry, my bad :-(

I did "emacs -Q", opened a .tex file (without AUCTeX to get Emacs'
tex-mode) and did 'M-x reftex-mode RET' there.  Emacs doesn't
native-compile anything into ~/.emacs.d/eln-cache/.

Best, Arash

Footnotes:
[1]  http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n164

bug#53497: 29.0.50; native-compile after restarting Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: larsi@gnus.org,  53497@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 17:33:22 +0100
> 
> I did "emacs -Q", opened a .tex file (without AUCTeX to get Emacs'
> tex-mode) and did 'M-x reftex-mode RET' there.  Emacs doesn't
> native-compile anything into ~/.emacs.d/eln-cache/.

And if you say "C-h f reftex-mode RET", does Emacs report it as
"compiled" or "natively compiled"?

bug#53497: 29.0.50; native-compile after restarting Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> And if you say "C-h f reftex-mode RET", does Emacs report it as
> "compiled" or "natively compiled"?

=> "compiled"

reftex-mode is an autoloaded interactive compiled Lisp function in
‘reftex.el’.