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

[Stefan Monnier]

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

Indeed, it's more like the `pdmp` fingerprint check.

> 1- We merge HASH1 and HASH3
>
>   - In this case everything will work as of now but certain operations
>     will become more difficult, the typical example is manually removing
>     all the eln left by an old Emacs configuration that is not anymore
>     in use (me and others do this quite often).

Can we erase those files based on their `mtime` instead
(maybe comparing their `mtime` to that of the `emacs` executable)?

> 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.
>
>   - We'd have name clashes for different eln coming from different
>     Emacs configurations/versions.

We can combine that with a shorter hash in the file-name.  The short
hash in the file name will eliminate the vast majority of name clashes.


        Stefan