GNU bug report logs - #73318
31.0.50; with-native-compilation=aot breaks exec -a emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 73318 <at> debbugs.gnu.org, larsi <at> gnus.org, acorallo <at> gnu.org, schwab <at> linux-m68k.org, shipmints <at> gmail.com
Subject: bug#73318: 31.0.50; with-native-compilation=aot breaks exec -a emacs
Date: Fri, 04 Oct 2024 22:09:50 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 73318 <at> debbugs.gnu.org,  larsi <at> gnus.org,  acorallo <at> gnu.org,
>    schwab <at> linux-m68k.org,  shipmints <at> gmail.com
> Date: Fri, 04 Oct 2024 12:51:59 -0400
> 
> > It isn't that easy.  We need to support 2 possible locations for the
> > preloaded *.eln files: in the source tree and in the installation
> > tree.  You now want us to look in yet a third place.  Take a look at
> > dump_do_dump_relocation where we look for the *.eln files.  What you
> > suggest is to add a third place to that code.
> 
> Yes.  I suggest that if installation_state == INSTALLED, and we fail to
> find an eln file in emacs_execdir, we fall back to look in PATH_EXEC (or
> some other path compiled into the Emacs binary).
> 
> But it occurs to me that there's another possible solution.  We already
> have a robust way to find the pdump.  My Emacs finds the pdump and loads
> it just fine.  Maybe we could look for the eln files relative to the
> pdump?

That means to throw away a lot of code in emacs.c which we use now and
was tested for several Emacs releases.  No, thanks, not for this
obscure scenario.

I still don't understand why you insist on not changing your script to
include the leading directories in argv[0].  It makes absolutely no
sense to me to invent new code in such a place, when the alternative
is so easy and reliable.

> > See above.  If you insist to go this much more complicated way, we'll
> > need to modify the code in dump_do_dump_relocation to use PATH_EXEC,
> > and deal with possible false positives.
> 
> Yes, I am willing to put in the effort to do that.

Makes no sense to me, so I urge you to reconsider.  You are
destabilizing Emacs for the benefit of an obscure use pattern that is
easy to fix without any changes in Emacs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.