1

The result of compiling emacs from source on Linux Mint 21 Cinnamon Edition was creation of FOUR identical executable files in the [src] directory:

1e2bec8a4a3c5c671fadd486d0590393  bootstrap-emacs
1e2bec8a4a3c5c671fadd486d0590393  emacs
1e2bec8a4a3c5c671fadd486d0590393  emacs-28.2.1
1e2bec8a4a3c5c671fadd486d0590393  temacs

Wouldn't it be not sufficient for installation purposes to copy the emacs-28.2.1 executable with different names to their installation destinations or create symlinks to it with the other names (which would be also possible on MS Windows)?

Is there any good reason I am not aware of for creating four identical executables of about 25 MByte in size?

UPDATE:

There are only three, not four files actually stored ... I have not checked the i-nodes of the files for hardlinks (thanks to Oliver Knodel for pointing it out in the comment). Below same list listing the i-nodes:

4873475 -rwxrwxr-x 1 neo neo 24566712 Mar 14 16:45 bootstrap-emacs
4873479 -rwxrwxr-x 2 neo neo 24566712 Mar 14 16:45 emacs
4873479 -rwxrwxr-x 2 neo neo 24566712 Mar 14 16:45 emacs-28.2.1
4873473 -rwxrwxr-x 1 neo neo 24566712 Mar 14 16:45 temacs

from which you can see that emacs and emacs-28.2.1 point to the same i-node and don't waste storage space.

Claudio
  • 410
  • 2
  • 11
  • I don't know the ins and outs of making Emacs, but after making it, you can do `make install; make clean` and all the intermediate artifacts go away. – NickD Mar 16 '23 at 11:49
  • @NickD : understand I right what you say if I conclude from it that there is no good reason I should be aware of but don't? In other words the simple answer to my question is: "No, there is no good reason you should be aware of for generating four identical binary files.", right? – Claudio Mar 16 '23 at 12:18
  • 1
    emacs and emacs-version (emacs-28.2.1) share the same inode, so it is a hard link. It is just one file on disk. About bootstrap-emacs and temacs, I don't know. – Oliver Knodel Mar 16 '23 at 13:39
  • If I meant that, I would have provided an answer to the question. My comment was that if you are worried about the space, there is a way to get rid of all the stuff that the process creates - that's all. – NickD Mar 16 '23 at 14:39
  • I am not worried about the space, but I also want to know: "Is there any good reason … for creating identical executable ", – Oliver Knodel Mar 16 '23 at 15:23
  • @OliverKnodel: just to be clear - my comment was directed towards the OP's comment (second comment in the sequence). – NickD Mar 16 '23 at 15:52

3 Answers3

2

This simple answer is "because that's how the Emacs build system works." bootstrap-emacs and temacs are both intermediate products of the build system, and at this point in time are probably progressively built up into the final executable which is then copied to either emacs or emacs-28.2.1. One of those is then hardlinked to the other in preparation for install.

It's been a very long time since I cared about the Emacs build system, but once upon a time temacs was the initial executable built entirely from compiled C code and lisp was then dumped into that to make emacs. When the build system was not parallel build friendly, you'd make -j4 and the build would die, but temacs would be built. You'd then do just make do dump the lisp and get emacs. Similar process if you wanted strip Emacs. Stripping the final emacs would wipeout some of the dumped lisp so you'd strip temacs and continue the build. I have no idea how the modern "pdumper" works, nor care, but I'd suspect that bootstrap-emacs is related to that.

nega
  • 3,091
  • 15
  • 21
1

temacs is the original compiled executable, before dumping. Under the unexec dump system, this will be very different to the eventual emacs excutable.

bootstrap-emacs is used to byte-compile all the lisp and some other build-time tasks.

emacs / emacs-<version> is the final executable.

Quoting the main Makefile:

Bootstrapping.

Bootstrapping right is difficult because of the circular dependencies. Furthermore, we have to deal with the fact that many compilation targets such as loaddefs.el or *.elc can typically be produced by any old Emacs executable, so we would like to avoid rebuilding them whenever we build a new Emacs executable.

(In other words, changing a single file src/foo.c would force dumping a new bootstrap-emacs, then re-byte-compiling all preloaded elisp files, and only then dump the actual src/emacs, which is not wrong, but is overkill in 99.99% of the cases.)

To solve the circularity, we use 2 different Emacs executables, "emacs" is the main target and "bootstrap-emacs" is the one used to build the *.elc and loaddefs.el files. To solve the freshness issue, in the past we tried various clever tricks, but now that we require GNU make, we can simply specify bootstrap-emacs$(EXEEXT) as an order-only prerequisite.

phils
  • 48,657
  • 3
  • 76
  • 115
  • Hmmm ... the explanation suggests that the files are build one upon the other and are "different". If it would be that way, how does it come that they are finally the same? P.S. sorry ... at my current level I can't follow what the citation speaks about. And why not use tmacs to "byte compile the lisp"? – Claudio Mar 20 '23 at 11:11
  • For the latter question, probably because (depending on the build) `temacs` can take more than two orders of magnitude longer to start than `emacs`, in which scenario the byte-compiling phase would take forever by comparison. – phils Mar 20 '23 at 12:08
  • For the "how come they are the same" question, as has been pointed out, `temacs` *isn't* necessarily the same. It may be (and is for you), but it depends. I don't know whether `bootstrap-emacs` is always the same as `emacs` -- maybe there are build options which also cause that not to be the case; but regardless, it's evidentially a separate executable primarily for the circularity issues discussed in the quote. – phils Mar 20 '23 at 12:13
  • N.b. Unless the portable dump files are identical for `emacs` and `bootstrap-emacs` then those executables would differ under the unexec dump model for the same reason as `temacs` would differ. Think of the executable and the portable dump file as a pair -- it's only identical to another pair if *both* parts are a match. – phils Mar 20 '23 at 13:08
  • Sorry ... the phrase " those executables would differ under the unexec dump model" is a kind of blackbox to me as I don't understand what "under the unexec dump model" means. I have also no idea what a "portable dump file" is. Anyway thanks for your efforts to provide explanations - I will incorporate the parts of them I understand into the summary. – Claudio Mar 20 '23 at 13:37
  • In general, the manual is always the first place to check. See `C-h i g (elisp)Building Emacs` – phils Mar 20 '23 at 21:20
0

Let's summarizethe outcome of the up to now ( status: 2023-03-20 ) given answers and posted comments:

Is there any good reason I am not aware of for creating four identical executables of about 25 MByte in size?

In the first step notice that only three of the files are actually taking storage space as two of them are hard-linked to each other.

In the second step become aware of that though you have experienced three of the same executable files the build process can under other circumstances also end up with three different files. It isn't generally the case that the executable files are identical.

Providing a really good explanation for the reason why multiple executable files are necessary would require conveying deep knowledge about how the build process works under the hood. Refer to the other answers for some details about it.

Checking if all of the three files are maybe identical to finally hardlink them together would be not worth the effort. You can always run make clean after the make install and, to say it with words by NickD, "all the intermediate artifacts will go away."

Claudio
  • 410
  • 2
  • 11
  • It's not just "historical". All three executables are used during the build. – phils Mar 20 '23 at 10:32
  • @phils : I have totally rewritten my summary reflecting the new status of given answers and provided comments. Is this summary now OK as it is, or are there still any not true statements which need to be corrected? – Claudio Mar 20 '23 at 14:23