Re: Finding the dump

[Daniel Colascione]

> Andreas Schwab wrote:
>> On Jan 27 2019, Daniel Colascione<address@hidden>  wrote:
>>
>>> Why not? Plenty of other programs do. Looking at realpath(argv[0]) is
>>> what
>>> _everyone_  does.
>> Which one?  They are all broken.
>
> Andreas is quite right here. One cannot trust realpath (argv[0]).
>
> This discussion is reminding me what a hassle that dump file is. I plan to
> look
> into the possibility of putting the dump file inside the executable
> (portably,
> of course) so that Emacs startup needn't worry about finding the dump
> file. This
> would be significantly better for installers and users.

No, he's wrong. Looking at argv[0] is normal practice. GCC does it. GDB
does it. Python does it. The Perl cookbook tells people to do it. Running
with the wrong argv[0] is an imaginary requirement that achieves nothing
and is required for no real-world use case. When is argv[0] ever actually
wrong?

Besides, we _already_ do the moral equivalent of realpath(argv[0]), in
init_cmdargs, which sets invocation-directory and from there various
internal paths, including installation-directory. If you run Emacs (26,
pre-pdumper) with the wrong argv0, and Emacs isn't installed, then Emacs
falls over and dies, unable to find simple.el. What we should do is use
the argv[0] directory more consistently, not make Emacs brittle and
non-relocatable for no reason.

It's unreal to see something we've done since at least 1994 and that GCC
and GDB *also* do, presumably for just as long, suddenly called some
intolerable bug. No, it's not.

We do need to make the case of argv[0] being a symlink work correctly. I
imagine gnulib has a realpath: we should use it. There's no other bug
here.