Re: [feature/native-comp] breakage on build

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> Date: Mon, 01 Feb 2021 16:20:17 +0000
> 
> > OK, thanks.  I understand the reasons now.  However, I'm not sure we
> > should encode all this information in the .eln file's name.  For
> > starters, some of those reasons are also true for *.elc files, right?
> > For example, suppose that a primitive that the .el file calls changed
> > its signature in backward-incompatible ways -- the .el files which
> > call it need to be recompiled, or else they will fail, either silently
> > or noisily.  Right?  But we don't encode those details in the names of
> > the *.elc files, do we?  Why should the *.eln files be different?
> 
> I think with eln the situation is considerably more sentitive than the
> elc one in this respect.  The reason is that we (on purpose) skip
> Ffuncall to call directly into C code, as a consequence an
> incompatibility will most certainly lead to a crash and not a runtime
> error.

Crash aside, I don't see the crucial difference, sorry.  And if we
detect incompatibility and prevent the crash, I seed no difference at
all, as that can happen with *.elc files as well.

> 2- We move HASH1 into the eln as metadata.
> 
>   - The limitation of 1 persists
> 
>   - To check that each eln is loadable one has: to 'dlopen' it, read the
>     metadata ('dlsym'), verify and in case reject.  This is certainly
>     way more expansive than directly searching for a given filename and
>     might impact negatively startup time, especially on certain OSes
>     where opening files is an expensive operation.

How much more expensive?  I'd be surprised to hear it's significant,
since in-memory operations are much faster than file I/O.  Is it
possible to measure the difference, so that we could make a decision
based on facts?

>   - We'd have name clashes for different eln coming from different
>     Emacs configurations/versions.

A different version will have a different directory, like it does now
with *.elc files.  As for different configurations: if you mean the
same architecture, how probable is that, for normal users?  If the
issue happens with Emacs developers, wed could design something
special for that case.

I guess I'm saying that using the file names to record this
information is not necessarily justified by the issues it is supposed
to solve, and there are alternative solutions with smaller costs.

> Shall we pick a length?  8 characters is probably more than okay but we
> can go for 16 if we prefer to stay on the safe side.

If 8 is enough, then why go for 16?  How is that safer?