Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in

[Paul Eggert]

Daniel Colascione wrote:
> If the temacs.in scheme *were* to
> break, it would have to be in such a way that 1) some change in Emacs or
> the environment resulted in temacs.in_1 (before the change) and
> temacs.in_2 (after the change) having the same hash, but temacs_1 (before
> the change) and temacs_2 (after the change) being different in a way that
> breaks pdumper. Can you think of such a scenario?

Sure:

   cd src
   make LDFLAGS="something"
   rm temacs
   make LDFLAGS="something else" temacs

Here, temacs.in_1 and temacs.in_2 are identical (because temacs.in is built just 
once) but temacs_1 and temacs_2 can differ in a way that breaks the portable dumper.

None of the approaches proposed in this thread work reliably in the presence of 
all plausible linkers, even ignoring the problem of hash collisions. All the 
approaches have false alarms (where the Emacs loader incorrectly reports an 
incompatibility) and false negatives (where the Emacs loader incorrectly fails 
to report an incompatibility that hurts later execution), and these flaws are 
pretty much inherent to the current fingerprint strategy. That's OK: the point 
of the fingerprint is not to be perfect (it can't be); it's only to be good 
enough. However, nobody knows even which of the discussed approaches will be 
best in practice, because nobody has practical experience with any of these 
approaches in a realistic deployment (and also, because we probably don't agree 
100% on what constitutes "best".)

> If you want to address the build time issue, just rewrite the fingerprint
> in place.

Although I don't agree that this approach works reliably (in the sense described 
above), it's better than the old temacs.in approach and it should be good enough 
in practice, so I installed the attached patch to do that.

0001-Replace-executable-s-fingerprint-in-place.patch
Description: Text Data