GNU bug report logs -
#46256
[feature/native-comp] AOT eln files ignored if run from build tree
Previous Next
Full log
Message #538 received at 46256 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Tue, Mar 09, 2021 at 18:30:57 +0200, Eli Zaretskii wrote:
> > Date: Tue, 09 Mar 2021 14:55:57 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, pipcet <at> gmail.com
> > > From: Andrea Corallo <akrl <at> sdf.org>
> > > Cc: pipcet <at> gmail.com, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> > > Date: Tue, 09 Mar 2021 07:03:01 +0000
> > > > Can you tell why are we loading the same .eln files more than once?
> > > I guess `load' was called two times on the same filename.
> > Is this likely to happen? Our code generally uses 'require', which
> > should avoid that.
> Answering my own question here: it can easily happen due to use of
> cc-require in cc-*.el files. Alan, why does CC mode use this
> technique? what is the purpose of always loading a Lisp file even if
> it was already loaded?
Are you sure? cc-require is intended just to compile a `require' form
(OK, it compiles (progn nil (require 'cc-vars)), but the byte compiler
will optimise the progn away).
When loading uncompiled cc-*.el, cc-require does fancy things to make
sure the cc-*.el is in the "correct" directory, but it shouldn't compile
any of this into the *.elc. Maybe there's a bug, somewhere.
The code in this area was written by Martin Stjernholm (my predecessor),
who was evidently having trouble with "wrong" versions of the *.el files
getting loaded.
I've had a bit of a look at the thread for bug #46256, but I can't really
follow it, at least not without a lot of effort. Might it be that the
..eln compiler is doing things on the .el file? I'm not at all familiar
with how the native compilation works, I'm afraid.
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 4 years and 129 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.