GNU bug report logs - #47800
[native-comp] could not resolve realpath of "emacs"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47800 in the body.
You can then email your comments to 47800 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [native-comp] could not resolve realpath of "emacs"
Date: Thu, 15 Apr 2021 16:09:26 +0200

Hi,

I install and symlink Emacs via Stow; i.e., Emacs is installed in
$HOME/.local/stow/emacs and then stowed into $HOME/.local.  Therefore,

  $HOME/.local/bin/emacs -> ../stow/emacs/bin/emacs
  $HOME/.local/libexec/emacs/28.0.50 -> ../../stow/emacs/libexec/emacs/28.0.50

and so on.  Since commit 0c1fc9d, running "emacs" in the terminal gives
me an error:

  could not resolve realpath of "emacs": No such file or directory

Also,

  $ which emacs
  $HOME/.local/bin/emacs

However, running "$HOME/.local/bin/emacs" works just fine, as does
"$HOME/.local/stow/emacs/bin/emacs".  "emacsclient" also runs fine.

There are no problems prior to commit 0c1fc9d.

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #8 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 02:17:46 +1200

Hi Dario.  See also:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44128

Message #11 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Thu, 15 Apr 2021 16:26:43 +0200

> Hi Dario.  See also:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44128

Thanks Phil.  What Eli wrote in message#28 there describes the issue
very well.  I would also like to point out that

  $ cd $HOME/.local/bin
  $ emacs

works.  (Note that it's "emacs" and not "./emacs", but there are no
problems with the latter either.)  I guess this can be closed in favor
of bug#44128.

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #14 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Thu, 15 Apr 2021 17:44:40 +0300

> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
> Date: Thu, 15 Apr 2021 16:09:26 +0200
> 
> I install and symlink Emacs via Stow; i.e., Emacs is installed in
> $HOME/.local/stow/emacs and then stowed into $HOME/.local.  Therefore,
> 
>   $HOME/.local/bin/emacs -> ../stow/emacs/bin/emacs
>   $HOME/.local/libexec/emacs/28.0.50 -> ../../stow/emacs/libexec/emacs/28.0.50
> 
> and so on.  Since commit 0c1fc9d, running "emacs" in the terminal gives
> me an error:
> 
>   could not resolve realpath of "emacs": No such file or directory

I think this is a duplicate of bug#44128, in its latest incarnation.

Message #17 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Thu, 15 Apr 2021 18:08:01 +0300

> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
> Date: Thu, 15 Apr 2021 16:26:43 +0200
> Cc: 47800 <at> debbugs.gnu.org
> 
> > Hi Dario.  See also:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44128
> 
> Thanks Phil.  What Eli wrote in message#28 there describes the issue
> very well.

Does the untested patch below fix the problem?

diff --git a/src/emacs.c b/src/emacs.c
index a256564..7eaaa28 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -846,7 +846,11 @@ load_pdump_find_executable (char const *argv0, ptrdiff_t *candidate_size)
       struct stat st;
       if (file_access_p (candidate, X_OK)
 	  && stat (candidate, &st) == 0 && S_ISREG (st.st_mode))
-	return candidate;
+	{
+	  if (lstat (candidate, &st) == 0 && S_ISLNK (st.st_mode))
+	    return realpath (candidate, NULL);
+	  return candidate;
+	}
       *candidate = '\0';
     }
   while (*path++ != '\0');

Message #20 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 10:57:22 +0200

[Message part 1 (text/plain, inline)]

> Does the untested patch below fix the problem?

Hi Eli,

Thanks for the patch.  Unfortunately it does not help as the raw_name
variable in set_invocation_vars is still not resolved according to PATH.

The patch I am attaching to this message _does_ resolve the issue, but I
am not sure about Windows.

Best regards,
Dario

[resolve-raw_name.patch (text/x-diff, inline)]

diff --git a/src/emacs.c b/src/emacs.c
index a256564..16fdc3c 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -460,8 +460,81 @@ real_filename (char *filename)
   return real_name;
 }
 
-/* Set `invocation-name' `invocation-directory'.  */
+/* Find a name (absolute or relative) of the Emacs executable whose
+   name (as passed into this program) is ARGV0.  Called early in
+   initialization by portable dumper loading code, so avoid Lisp and
+   associated machinery.  Return a heap-allocated string giving a name
+   of the Emacs executable, or an empty heap-allocated string or NULL
+   if not found.  Store into *CANDIDATE_SIZE a lower bound on the size
+   of any heap allocation.  */
+static char *
+find_executable (char const *argv0, ptrdiff_t *candidate_size)
+{
+  *candidate_size = 0;
+
+  /* Use xstrdup etc. to allocate storage, so as to call our private
+     implementation of malloc, since the caller calls our free.  */
+#ifdef WINDOWSNT
+  char *prog_fname = w32_my_exename ();
+  return prog_fname ? xstrdup (prog_fname) : NULL;
+#else  /* !WINDOWSNT */
+  char *candidate = NULL;
+
+  /* If the executable name contains a slash, we have some kind of
+     path already, so just copy it.  */
+  eassert (argv0);
+  if (strchr (argv0, DIRECTORY_SEP))
+    return xstrdup (argv0);
+  ptrdiff_t argv0_length = strlen (argv0);
+
+  const char *path = getenv ("PATH");
+  if (!path)
+    {
+      /* Default PATH is implementation-defined, so we don't know how
+         to conduct the search.  */
+      return NULL;
+    }
+
+  /* Actually try each concatenation of a path element and the
+     executable basename.  */
+  do
+    {
+      static char const path_sep[] = { SEPCHAR, '\0' };
+      ptrdiff_t path_part_length = strcspn (path, path_sep);
+      const char *path_part = path;
+      path += path_part_length;
+      if (path_part_length == 0)
+        {
+          path_part = ".";
+          path_part_length = 1;
+        }
+      ptrdiff_t needed = path_part_length + 1 + argv0_length + 1;
+      if (*candidate_size <= needed)
+	{
+	  xfree (candidate);
+	  candidate = xpalloc (NULL, candidate_size,
+			       needed - *candidate_size + 1, -1, 1);
+	}
+      memcpy (candidate + 0, path_part, path_part_length);
+      candidate[path_part_length] = DIRECTORY_SEP;
+      memcpy (candidate + path_part_length + 1, argv0, argv0_length + 1);
+      struct stat st;
+      if (file_access_p (candidate, X_OK)
+	  && stat (candidate, &st) == 0 && S_ISREG (st.st_mode))
+	{
+	  if (lstat (candidate, &st) == 0 && S_ISLNK (st.st_mode))
+	    return realpath (candidate, NULL);
+	  return candidate;
+	}
+      *candidate = '\0';
+    }
+  while (*path++ != '\0');
+
+  return candidate;
+#endif	/* !WINDOWSNT */
+}
 
+/* Set `invocation-name' `invocation-directory'.  */
 static void
 set_invocation_vars (char *argv0, char const *original_pwd)
 {
@@ -486,7 +559,9 @@ set_invocation_vars (char *argv0, char const *original_pwd)
       raw_name = build_unibyte_string (argv0);
   }
 #else
-  raw_name = build_unibyte_string (argv0);
+  ptrdiff_t bufsize;
+  char *executable = find_executable (argv0, &bufsize);
+  raw_name = build_unibyte_string (executable);
 #endif
 
   /* Add /: to the front of the name
@@ -785,76 +860,6 @@ dump_error_to_string (int result)
     }
 }
 
-/* Find a name (absolute or relative) of the Emacs executable whose
-   name (as passed into this program) is ARGV0.  Called early in
-   initialization by portable dumper loading code, so avoid Lisp and
-   associated machinery.  Return a heap-allocated string giving a name
-   of the Emacs executable, or an empty heap-allocated string or NULL
-   if not found.  Store into *CANDIDATE_SIZE a lower bound on the size
-   of any heap allocation.  */
-static char *
-load_pdump_find_executable (char const *argv0, ptrdiff_t *candidate_size)
-{
-  *candidate_size = 0;
-
-  /* Use xstrdup etc. to allocate storage, so as to call our private
-     implementation of malloc, since the caller calls our free.  */
-#ifdef WINDOWSNT
-  char *prog_fname = w32_my_exename ();
-  return prog_fname ? xstrdup (prog_fname) : NULL;
-#else  /* !WINDOWSNT */
-  char *candidate = NULL;
-
-  /* If the executable name contains a slash, we have some kind of
-     path already, so just copy it.  */
-  eassert (argv0);
-  if (strchr (argv0, DIRECTORY_SEP))
-    return xstrdup (argv0);
-  ptrdiff_t argv0_length = strlen (argv0);
-
-  const char *path = getenv ("PATH");
-  if (!path)
-    {
-      /* Default PATH is implementation-defined, so we don't know how
-         to conduct the search.  */
-      return NULL;
-    }
-
-  /* Actually try each concatenation of a path element and the
-     executable basename.  */
-  do
-    {
-      static char const path_sep[] = { SEPCHAR, '\0' };
-      ptrdiff_t path_part_length = strcspn (path, path_sep);
-      const char *path_part = path;
-      path += path_part_length;
-      if (path_part_length == 0)
-        {
-          path_part = ".";
-          path_part_length = 1;
-        }
-      ptrdiff_t needed = path_part_length + 1 + argv0_length + 1;
-      if (*candidate_size <= needed)
-	{
-	  xfree (candidate);
-	  candidate = xpalloc (NULL, candidate_size,
-			       needed - *candidate_size + 1, -1, 1);
-	}
-      memcpy (candidate + 0, path_part, path_part_length);
-      candidate[path_part_length] = DIRECTORY_SEP;
-      memcpy (candidate + path_part_length + 1, argv0, argv0_length + 1);
-      struct stat st;
-      if (file_access_p (candidate, X_OK)
-	  && stat (candidate, &st) == 0 && S_ISREG (st.st_mode))
-	return candidate;
-      *candidate = '\0';
-    }
-  while (*path++ != '\0');
-
-  return candidate;
-#endif	/* !WINDOWSNT */
-}
-
 static void
 load_pdump (int argc, char **argv, char const *original_pwd)
 {
@@ -906,7 +911,7 @@ load_pdump (int argc, char **argv, char const *original_pwd)
      encoding the system natively uses for filesystem access, so
      there's no need for character set conversion.  */
   ptrdiff_t bufsize;
-  dump_file = load_pdump_find_executable (argv[0], &bufsize);
+  dump_file = find_executable (argv[0], &bufsize);
 
   /* If we couldn't find our executable, go straight to looking for
      the dump in the hardcoded location.  */

[Message part 3 (text/plain, inline)]

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #23 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 11:08:07 +0200

I suppose one should also check the return value of find_executable
before using it for raw_name.

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #26 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 11:23:17 +0200

Also, the more I look at the patch I attached above, the worse it seems,
so...

But I can at least confirm that the issue is that raw_name is not
resolved according to PATH prior to the call of real_filename in

  char *filename = real_filename (SSDATA (raw_name));

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #29 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: psainty <at> orcon.net.nz, Eli Zaretskii <eliz <at> gnu.org>, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 09:27:51 +0000

Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com> writes:

Hi Dario, thanks for the patch.

> Also, the more I look at the patch I attached above, the worse it seems,
> so...

Why?

> But I can at least confirm that the issue is that raw_name is not
> resolved according to PATH prior to the call of real_filename in
>
>   char *filename = real_filename (SSDATA (raw_name));

I agree that's the issue.

Thanks

  Andrea

Message #32 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: psainty <at> orcon.net.nz, Eli Zaretskii <eliz <at> gnu.org>, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 11:37:49 +0200

Hi Andrea,

>> Also, the more I look at the patch I attached above, the worse it seems,
>> so...
>
> Why?

These are the points that make me suspicious:

  1. I am not sure if the subsequent call to Ffind_file_name_handler
     would work correctly.
  2. There is already a search over exec_path happening immediately
     afterwards.
  3. Moreover, I am not sure what real_filename would do when a handler
     is found and raw_name is prefixed by slash-colon.

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #35 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: wilde <at> sha-bang.de
To: 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 11:53:58 +0200

Hi *,

FWIW: when /proc/self/exe exists it is a symlink to the currently
running executable, that should make the implementation of
find_executable() in these cases straight forward.

Basically:
  realpath ("/proc/self/exe", NULL);
should do the job.

/proc/self/run exists per default on most (all?) GNU/Linux Systems and
on my i386 NetBSD 9.1 per default.  In case of *BSD this might be a
Linux compatibility feature but I'm not sure -- needs checking.

cheers
sascha

Message #38 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 22:56:51 +1200

On 16/04/21 9:27 pm, Andrea Corallo wrote:
> Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com> writes:
>> But I can at least confirm that the issue is that raw_name is not
>> resolved according to PATH prior to the call of real_filename in
>>
>>   char *filename = real_filename (SSDATA (raw_name));
> 
> I agree that's the issue.

My (perhaps naive) impression is that set_invocation_vars should
be using load_pdump_find_executable (or a copy of the result that
it already established) to establish what argv0 is referring to?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46790#38 may have
been driving at the same point.

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44128#49 I'm
seeing load_pdump_find_executable successfully figuring out the
genuine path to the executable every time.

Message #41 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 23:32:42 +1200

On 16/04/21 10:56 pm, Phil Sainty wrote:
> In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44128#49 I'm
> seeing load_pdump_find_executable successfully figuring out the
> genuine path to the executable every time.

Clarification: It's only figuring it out on account of Eli's patch:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-04/msg00678.html

So as Eli said subsequently: "It moves one step closer, AFAICT: the
real file name of the Emacs executable is now correctly identified."
-- https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-04/msg00715.html

So IIUC, firstly we want that patch, and *then* that result can be
used by set_invocation_vars ?

Message #44 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 15:32:29 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
> Date: Fri, 16 Apr 2021 09:27:51 +0000
> 
> > But I can at least confirm that the issue is that raw_name is not
> > resolved according to PATH prior to the call of real_filename in
> >
> >   char *filename = real_filename (SSDATA (raw_name));
> 
> I agree that's the issue.

I think the issue is slightly more complex.

Andrea, is native-compilation supported with unexec, or only with
pdumper?  If the former, where in the code and when do we load the
preloaded *.eln files? are they dumped into the Emacs executable?

If we don't support native-compilation with unexec, we should reject
that combination in configure, right?

Message #49 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 19:23:51 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
>> Date: Fri, 16 Apr 2021 09:27:51 +0000
>> 
>> > But I can at least confirm that the issue is that raw_name is not
>> > resolved according to PATH prior to the call of real_filename in
>> >
>> >   char *filename = real_filename (SSDATA (raw_name));
>> 
>> I agree that's the issue.
>
> I think the issue is slightly more complex.

That's very possible today I had really no time to reproduce and
investigate this in details sorry.

> Andrea, is native-compilation supported with unexec, or only with
> pdumper?

Only pdumper.

> If the former, where in the code and when do we load the
> preloaded *.eln files? are they dumped into the Emacs executable?

We re-load the eln for each compilation unit around pdumper.c:5277.  The
position of the eln is already stored in CU object (formed in
loadup.el:467).

> If we don't support native-compilation with unexec, we should reject
> that combination in configure, right?

That's correct.

Thanks

  Andrea

Message #52 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 22:38:28 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: dario.gjorgjevski <at> gmail.com, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
> Date: Fri, 16 Apr 2021 19:23:51 +0000
> 
> >> >   char *filename = real_filename (SSDATA (raw_name));
> >> 
> >> I agree that's the issue.
> >
> > I think the issue is slightly more complex.
> 
> That's very possible today I had really no time to reproduce and
> investigate this in details sorry.
> 
> > Andrea, is native-compilation supported with unexec, or only with
> > pdumper?
> 
> Only pdumper.

OK, that simplifies the solution.

The problem we need to solve is that we have two decisions that run in
parallel, but are not really synchronized: where to look for the
pdumper file and where to look for the *.eln files.  These two must
correspond to each other, but currently they have little in common,
which is a problem waiting to bite us.

The other issue is the reliance on Vinvocation_directory.  To rely on
it, we must change how and when it is computed, and that will most
probably change its value in some use cases.  So I think we need to
leave the Vinvocation_directory calculation as it was before, in
init_cmdargs, and use other variables to tell pdumper_load how to
resolve the native-lisp directory when restoring from the pdumper
file.

I'm currently working on making these changes, and hope to have a
solution which will solve all the known issues with symlinks etc.

Message #55 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Fri, 16 Apr 2021 20:07:01 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: dario.gjorgjevski <at> gmail.com, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
>> Date: Fri, 16 Apr 2021 19:23:51 +0000
>> 
>> >> >   char *filename = real_filename (SSDATA (raw_name));
>> >> 
>> >> I agree that's the issue.
>> >
>> > I think the issue is slightly more complex.
>> 
>> That's very possible today I had really no time to reproduce and
>> investigate this in details sorry.
>> 
>> > Andrea, is native-compilation supported with unexec, or only with
>> > pdumper?
>> 
>> Only pdumper.
>
> OK, that simplifies the solution.
>
> The problem we need to solve is that we have two decisions that run in
> parallel, but are not really synchronized: where to look for the
> pdumper file and where to look for the *.eln files.  These two must
> correspond to each other, but currently they have little in common,
> which is a problem waiting to bite us.
>
> The other issue is the reliance on Vinvocation_directory.  To rely on
> it, we must change how and when it is computed, and that will most
> probably change its value in some use cases.  So I think we need to
> leave the Vinvocation_directory calculation as it was before, in
> init_cmdargs, and use other variables to tell pdumper_load how to
> resolve the native-lisp directory when restoring from the pdumper
> file.
>
> I'm currently working on making these changes, and hope to have a
> solution which will solve all the known issues with symlinks etc.

Thanks, I'm sorry in the last day I could not help more with this issue.

  Andrea

Message #58 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Sat, 17 Apr 2021 10:13:24 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: dario.gjorgjevski <at> gmail.com, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
> Date: Fri, 16 Apr 2021 20:07:01 +0000
> 
> > I'm currently working on making these changes, and hope to have a
> > solution which will solve all the known issues with symlinks etc.
> 
> Thanks, I'm sorry in the last day I could not help more with this issue.

That's okay, we should have done this earlier.  It does mean we will
postpone the merge of the branch for a few days, as I'd like to see
that at least most of the issues with symlinks and other "unusual"
installation methods work.

Message #61 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Sat, 17 Apr 2021 07:39:33 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: dario.gjorgjevski <at> gmail.com, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
>> Date: Fri, 16 Apr 2021 20:07:01 +0000
>> 
>> > I'm currently working on making these changes, and hope to have a
>> > solution which will solve all the known issues with symlinks etc.
>> 
>> Thanks, I'm sorry in the last day I could not help more with this issue.
>
> That's okay, we should have done this earlier.  It does mean we will
> postpone the merge of the branch for a few days, as I'd like to see
> that at least most of the issues with symlinks and other "unusual"
> installation methods work.

That's sensible, thanks

  Andrea

Message #64 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: jonas <at> bernoul.li, psainty <at> orcon.net.nz, wilde <at> sha-bang.de,
 Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: 44128 <at> debbugs.gnu.org, 47800 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: [feature/native-comp] When invoking a symlink to
 the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 16:58:40 +0300

> Date: Fri, 16 Apr 2021 18:08:00 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: psainty <at> orcon.net.nz, akrl <at> sdf.org, 44128 <at> debbugs.gnu.org, eli <at> gnu.org
> 
> > From: Jonas Bernoulli <jonas <at> bernoul.li>
> > Date: Fri, 16 Apr 2021 15:21:47 +0200
> > Cc: 44128 <at> debbugs.gnu.org, eli <at> gnu.org
> > 
> > Andrea Corallo <akrl <at> sdf.org> writes:
> > 
> > > I've pushed 0c1fc9d581 that seams to work for me, please have a try.
> > 
> > Unfortunately this still doesn't work (as of f9c1008ced):
> > 
> >   $ emacs
> >   emacs: could not resolve realpath of "emacs": No such file or directory
> >   $ which emacs
> >   /usr/local/bin/emacs
> >   $ ls -l /usr/local/bin/emacs
> >   lrwxrwxrwx 1 root staff 55 Apr 16 14:51 /usr/local/bin/emacs -> /home/jonas/git/src/emacs/feature
> > 
> > But this works:
> > 
> >   $ /home/jonas/git/src/emacs/feature/native-comp/src/emacs
> > 
> > And so does:
> > 
> >   $ cat /usr/local/bin/emacs
> >   #!/bin/sh
> >   /home/jonas/git/src/emacs/feature/native-comp/src/emacs "$@"
> >   $ emacs
> 
> Thanks, I think I understand the issues, and I'm working on a fix.

Please try the latest native-comp branch.  If it still doesn't solve
the problem with installing Emacs via symlinks, or if there are some
adverse side-effects of the changes I made, please report the details.

In a nutshell, Emacs should now decide where to look for its pdumper
file and where to look for the *.eln files in a synchronized manner.
I hope I got all the varieties of the symlinks involved correctly (but
I couldn't test all the possible variants, only some of them).

Please be sure to test both installed and uninstalled binaries, and
please verify that comp-eln-load-path has the right value after Emacs
loads in both cases (the last element of the list should in each case
reflect where the *.eln files will be looked for).

TIA

Message #67 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: wilde <at> sha-bang.de
Cc: 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Sat, 17 Apr 2021 17:00:42 +0300

> From: wilde <at> sha-bang.de
> Date: Fri, 16 Apr 2021 11:53:58 +0200
> 
> FWIW: when /proc/self/exe exists it is a symlink to the currently
> running executable, that should make the implementation of
> find_executable() in these cases straight forward.
> 
> Basically:
>   realpath ("/proc/self/exe", NULL);
> should do the job.

This was discussed, but AFAIR people felt uneasy with using it.

Message #70 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>, 44128 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 02:13:19 +1200

On 18/04/21 1:58 am, Eli Zaretskii wrote:
> Please try the latest native-comp branch.

Unfortunately that didn't compile for me:

  CC       emacs.o
emacs.c: In function ‘load_pdump’:
emacs.c:903:3: error: a label can only be part of a statement and a declaration is not a statement
  903 |   const char *argv0_base = "emacs";
      |   ^~~~~
Makefile:385: recipe for target 'emacs.o' failed
make[1]: *** [emacs.o] Error 1



$ gcc --version
gcc (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



My 'configure' result was:

Configured for 'x86_64-pc-linux-gnu'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -g3 -O2
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          LUCID
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 yes
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng16 -lz
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   yes
  Does Emacs use -llcms2?                                 yes
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  no
  Does Emacs support sound?                               no
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lglibc (inotify)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use HarfBuzz?                                yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use -lsystemd?                               no
  Does Emacs use -ljansson?                               yes
  Does Emacs use the GMP library?                         yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   yes

Message #73 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: psainty <at> orcon.net.nz, dario.gjorgjevski <at> gmail.com, 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Sat, 17 Apr 2021 17:16:59 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: dario.gjorgjevski <at> gmail.com, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org
> Date: Fri, 16 Apr 2021 19:23:51 +0000
> 
> > If we don't support native-compilation with unexec, we should reject
> > that combination in configure, right?
> 
> That's correct.

Oh, I see we already do that.  I guess that's what you were trying to
say, but I misunderstood...

Thanks.

Message #76 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 17:29:51 +0300

> Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de,
>  Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>, 44128 <at> debbugs.gnu.org,
>  47800 <at> debbugs.gnu.org, akrl <at> sdf.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Sun, 18 Apr 2021 02:13:19 +1200
> 
>   CC       emacs.o
> emacs.c: In function ‘load_pdump’:
> emacs.c:903:3: error: a label can only be part of a statement and a declaration is not a statement
>   903 |   const char *argv0_base = "emacs";
>       |   ^~~~~
> Makefile:385: recipe for target 'emacs.o' failed
> make[1]: *** [emacs.o] Error 1

How about now?

Message #79 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 03:00:17 +1200

On 18/04/21 2:29 am, Eli Zaretskii wrote:
> How about now?

This time it compiled; but with the following warnings, and
when I run it from the installed location (whether using the
absolute path or a symlink) I get a seg fault / core dump:

$ /home/phil/emacs/native-comp/usr/local/bin/emacs --version
Segmentation fault (core dumped)

Running the uninstalled version works:

$ ./src/emacs --version
GNU Emacs 28.0.50
Copyright (C) 2021 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.


-Phil (finished for the night, but can test more tomorrow)


  CC       emacs.o
In function ‘load_pdump’,
    inlined from ‘main’ at emacs.c:1289:5:
emacs.c:920:13: warning: argument 1 null where non-null expected [-Wnonnull]
  920 |   needed += strlen (strip_suffix) - strlen (suffix) + strlen (go_up);
      |             ^~~~~~~~~~~~~~~~~~~~~
In file included from ../lib/string.h:41,
                 from lisp.h:29,
                 from emacs.c:33:
emacs.c: In function ‘main’:
/usr/include/string.h:384:15: note: in a call to function ‘strlen’ declared here
  384 | extern size_t strlen (const char *__s)
      |               ^~~~~~
In file included from /usr/include/stdio.h:862,
                 from ../lib/stdio.h:43,
                 from lisp.h:4731,
                 from emacs.c:33:
In function ‘sprintf’,
    inlined from ‘load_pdump’ at emacs.c:927:3,
    inlined from ‘main’ at emacs.c:1289:5:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   33 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   34 |       __bos (__s), __fmt, __va_arg_pack ());
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Message #82 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 18:12:04 +0300

> Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
>  dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Sun, 18 Apr 2021 03:00:17 +1200
> 
> On 18/04/21 2:29 am, Eli Zaretskii wrote:
> > How about now?
> 
> This time it compiled; but with the following warnings, and
> when I run it from the installed location (whether using the
> absolute path or a symlink) I get a seg fault / core dump:

Sorry about that.  Next try, please.

Message #85 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, Phil Sainty <psainty <at> orcon.net.nz>, 47800 <at> debbugs.gnu.org,
 wilde <at> sha-bang.de, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 17:39:28 +0200

> Sorry about that.  Next try, please.

Hi Eli,

The most recent commit, b8d3860, works fine here.  (I previously had the
same segfault as Phil.)

Many thanks for all your work!

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #88 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 wilde <at> sha-bang.de, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 18:48:33 +0300

> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
> Cc: Phil Sainty <psainty <at> orcon.net.nz>,  jonas <at> bernoul.li,
>   wilde <at> sha-bang.de,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
>   akrl <at> sdf.org
> Date: Sat, 17 Apr 2021 17:39:28 +0200
> 
> The most recent commit, b8d3860, works fine here.  (I previously had the
> same segfault as Phil.)

Great, thanks for testing.

Message #91 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: wilde <at> sha-bang.de
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47800 <at> debbugs.gnu.org
Subject: Re: bug#47800: [native-comp] could not resolve realpath of "emacs"
Date: Sat, 17 Apr 2021 21:12:48 +0200

Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: wilde <at> sha-bang.de
>> Date: Fri, 16 Apr 2021 11:53:58 +0200
>> 
>> FWIW: when /proc/self/exe exists it is a symlink to the currently
>> running executable, that should make the implementation of
>> find_executable() in these cases straight forward.
>> 
>> Basically:
>>   realpath ("/proc/self/exe", NULL);
>> should do the job.
>
> This was discussed, but AFAIR people felt uneasy with using it.

I wonder why -- but thats not too important as long as we have a
reliable solution anyway.  :)

Message #94 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: wilde <at> sha-bang.de
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>, 44128 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 21:15:24 +0200

Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
>> Cc: Phil Sainty <psainty <at> orcon.net.nz>,  jonas <at> bernoul.li,
>>   wilde <at> sha-bang.de,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
>>   akrl <at> sdf.org
>> Date: Sat, 17 Apr 2021 17:39:28 +0200
>> 
>> The most recent commit, b8d3860, works fine here.  (I previously had the
>> same segfault as Phil.)
>
> Great, thanks for testing.

I'm very happy to confirm that 75c898e (one past b8d3860) also works as
expected on NetBSD 9.1.

Thanks a  lot for fixing this!

Message #97 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: wilde <at> sha-bang.de
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 22:18:59 +0300

> From: wilde <at> sha-bang.de
> Cc: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>,  psainty <at> orcon.net.nz,
>   jonas <at> bernoul.li,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
>   akrl <at> sdf.org
> Date: Sat, 17 Apr 2021 21:15:24 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
> >> Cc: Phil Sainty <psainty <at> orcon.net.nz>,  jonas <at> bernoul.li,
> >>   wilde <at> sha-bang.de,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
> >>   akrl <at> sdf.org
> >> Date: Sat, 17 Apr 2021 17:39:28 +0200
> >> 
> >> The most recent commit, b8d3860, works fine here.  (I previously had the
> >> same segfault as Phil.)
> >
> > Great, thanks for testing.
> 
> I'm very happy to confirm that 75c898e (one past b8d3860) also works as
> expected on NetBSD 9.1.

Thanks for testing this.

Message #100 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: wilde <at> sha-bang.de
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 21:32:23 +0200

Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: wilde <at> sha-bang.de
>> Cc: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>,  psainty <at> orcon.net.nz,
>>   jonas <at> bernoul.li,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
>>   akrl <at> sdf.org
>> Date: Sat, 17 Apr 2021 21:15:24 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>> >> From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
>> >> Cc: Phil Sainty <psainty <at> orcon.net.nz>,  jonas <at> bernoul.li,
>> >>   wilde <at> sha-bang.de,  47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,
>> >>   akrl <at> sdf.org
>> >> Date: Sat, 17 Apr 2021 17:39:28 +0200
>> >> 
>> >> The most recent commit, b8d3860, works fine here.  (I previously had the
>> >> same segfault as Phil.)
>> >
>> > Great, thanks for testing.
>> 
>> I'm very happy to confirm that 75c898e (one past b8d3860) also works as
>> expected on NetBSD 9.1.
>
> Thanks for testing this.

My pleasure.

However, on my test build (for this issue) on GNU/Linux unfortunately I
do still see issues:

# The situation after setup
# (build with --prefix=/home/wilde/apps/emacs-native-dev and installed
# with make install):

% ls -l `which emacs`
lrwxrwxrwx 1 wilde wilde 13 Apr 17 21:21 /home/wilde/apps/emacs-native-dev/bin/emacs -> emacs-28.0.50*
% ls -l `which emacs-28.0.50` 
-rwxr-xr-x 1 wilde wilde 25866768 Apr 17 21:21 /home/wilde/apps/emacs-native-dev/bin/emacs-28.0.50*

# The problem:

% emacs                      
emacs: /home/wilde/apps/emacs-native-dev/libexec/emacs/28.0.50/x86_64-p/home/wilde/apps/emacs-native-dev/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../native-lisp/28.0.50-f13b7cda/preloaded/frame-aa2cd9f8-88c2b85c.eln: cannot open shared object file: No such file or directory
1 wilde <at> marklar[~/src/stdsrc/emacs-native-comp_BUILD]

# What works:

% emacs-28.0.50
# → emacs starts fine.

FWIW, The file not found when invoked using the symlink "emasc" is at:
/home/wilde/apps/emacs-native-dev/lib/emacs/28.0.50/native-lisp/28.0.50-f13b7cda/preloaded/frame-aa2cd9f8-88c2b85c.eln

cheers
sascha

Message #103 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 wilde <at> sha-bang.de, dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#44128: [feature/native-comp] When invoking a symlink to the
 'emacs' binary Emacs fails to start
Date: Sat, 17 Apr 2021 23:40:43 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The version of master that I am running is from Dec 5.
I always run it through a symlink.

So I think the bug was introduced since then.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #106 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 wilde <at> sha-bang.de, dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#44128: [feature/native-comp] When invoking a symlink to the
 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 09:58:27 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, wilde <at> sha-bang.de,
> 	dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org,
> 	47800 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Sat, 17 Apr 2021 23:40:43 -0400
> 
> The version of master that I am running is from Dec 5.
> I always run it through a symlink.
> 
> So I think the bug was introduced since then.

You are not running the native-comp branch, that's why you don't see
the problem.  The problem doesn't exist on the master branch, even not
today.

Message #109 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 19:40:20 +1200

Thank you Eli, this looks good to me too.

I tested with the following set of symlinks:

/home/phil/bin/emacs                         -> /home/phil/emacs/native-comp/usr/local/bin/emacs
/home/phil/bin/emacs-native-comp             -> /home/phil/emacs/native-comp/usr/local/bin/emacs
/home/phil/bin/emacs-28.0.50                 -> /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50
/home/phil/bin/emacs-native-comp-28.0.50     -> /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50
/home/phil/bin/emacs-native-comp-uninstalled -> /home/phil/emacs/native-comp/shallow-repository/src/emacs

For each of those symlinks, and also the absolute paths for the
link targets, I tested running them from multiple directories.
These included the directories of the real binaries, plus two
other directories containing a file or sub-directory named 'emacs':

drwxrwxr-x 25 phil phil 4096 Mar 28 23:30 /home/phil/emacs
-rw-rw-r--  1 phil phil    0 Apr 18 11:34 /tmp/emacs

In each test I ran --batch --eval "(prin1 comp-eln-load-path)"

$ (for dir in / /home /home/phil /home/phil/bin /home/phil/emacs /home/phil/emacs/native-comp/usr/local/bin /home/phil/emacs/native-comp/shallow-repository/src /tmp; do echo; echo $dir; cd $dir; for E in emacs emacs-native-comp emacs-28.0.50 emacs-native-comp-28.0.50 /home/phil/emacs/native-comp/usr/local/bin/emacs /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50 emacs-native-comp-uninstalled /home/phil/emacs/native-comp/shallow-repository/src/emacs; do $E --batch --eval "(prin1 comp-eln-load-path)"; echo " -- $E"; done; done)

Nothing failed, and for every directory the output was the same:

("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-native-comp
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-28.0.50
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-native-comp-28.0.50
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- /home/phil/emacs/native-comp/usr/local/bin/emacs
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/shallow-repository/native-lisp/") -- emacs-native-comp-uninstalled
("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/shallow-repository/native-lisp/") -- /home/phil/emacs/native-comp/shallow-repository/src/emacs


-Phil

Message #112 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 11:09:56 +0300

> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
>  dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Sun, 18 Apr 2021 19:40:20 +1200
> 
> $ (for dir in / /home /home/phil /home/phil/bin /home/phil/emacs /home/phil/emacs/native-comp/usr/local/bin /home/phil/emacs/native-comp/shallow-repository/src /tmp; do echo; echo $dir; cd $dir; for E in emacs emacs-native-comp emacs-28.0.50 emacs-native-comp-28.0.50 /home/phil/emacs/native-comp/usr/local/bin/emacs /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50 emacs-native-comp-uninstalled /home/phil/emacs/native-comp/shallow-repository/src/emacs; do $E --batch --eval "(prin1 comp-eln-load-path)"; echo " -- $E"; done; done)
> 
> Nothing failed, and for every directory the output was the same:
> 
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-native-comp
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-28.0.50
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- emacs-native-comp-28.0.50
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- /home/phil/emacs/native-comp/usr/local/bin/emacs
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/usr/local/lib/emacs/28.0.50/native-lisp/") -- /home/phil/emacs/native-comp/usr/local/bin/emacs-28.0.50
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/shallow-repository/native-lisp/") -- emacs-native-comp-uninstalled
> ("/home/phil/.emacs.d/eln-cache/" "/home/phil/emacs/native-comp/shallow-repository/native-lisp/") -- /home/phil/emacs/native-comp/shallow-repository/src/emacs

Thanks for testing, this looks very promising.

Message #115 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: wilde <at> sha-bang.de
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 11:42:32 +0300

> From: wilde <at> sha-bang.de
> Cc: dario.gjorgjevski <at> gmail.com,  psainty <at> orcon.net.nz,  jonas <at> bernoul.li,
>   47800 <at> debbugs.gnu.org,  44128 <at> debbugs.gnu.org,  akrl <at> sdf.org
> Date: Sat, 17 Apr 2021 21:32:23 +0200
> 
> % ls -l `which emacs`
> lrwxrwxrwx 1 wilde wilde 13 Apr 17 21:21 /home/wilde/apps/emacs-native-dev/bin/emacs -> emacs-28.0.50*
> % ls -l `which emacs-28.0.50` 
> -rwxr-xr-x 1 wilde wilde 25866768 Apr 17 21:21 /home/wilde/apps/emacs-native-dev/bin/emacs-28.0.50*
> 
> # The problem:
> 
> % emacs                      
> emacs: /home/wilde/apps/emacs-native-dev/libexec/emacs/28.0.50/x86_64-p/home/wilde/apps/emacs-native-dev/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../native-lisp/28.0.50-f13b7cda/preloaded/frame-aa2cd9f8-88c2b85c.eln: cannot open shared object file: No such file or directory

There's something here that I'm missing.  The file name it tries is
clearly a result of some invalid concatenation of string, but I don't
quite see how that could happen.

Can you step through the code with GDB?  If yes, I will ask to show
values of some variables, and that will hopefully pinpoint the buggy
code.

Thanks.

Message #118 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: wilde <at> sha-bang.de
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: bug#47800: bug#44128: [feature/native-comp] When
 invoking a symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 12:01:54 +0300

> Date: Sun, 18 Apr 2021 11:42:32 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
>  dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
> 
> Can you step through the code with GDB?  If yes, I will ask to show
> values of some variables, and that will hopefully pinpoint the buggy
> code.

But before you do anything else, please try the latest branch, where I
fixed some thinko.

Thanks.

Message #121 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: wilde <at> sha-bang.de
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: bug#47800: bug#44128: [feature/native-comp] When
 invoking a symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 14:24:15 +0200

Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Date: Sun, 18 Apr 2021 11:42:32 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
>>  dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
>> 
>> Can you step through the code with GDB?  If yes, I will ask to show
>> values of some variables, and that will hopefully pinpoint the buggy
>> code.
>
> But before you do anything else, please try the latest branch, where I
> fixed some thinko.

That latest change fixed it for me.

Once again, may thanks for your work!

cheers
sascha

Message #124 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: wilde <at> sha-bang.de
Cc: jonas <at> bernoul.li, psainty <at> orcon.net.nz, 47800 <at> debbugs.gnu.org,
 dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: bug#47800: bug#44128: [feature/native-comp] When
 invoking a symlink to the 'emacs' binary Emacs fails to start
Date: Sun, 18 Apr 2021 16:00:39 +0300

> From: wilde <at> sha-bang.de
> Cc: jonas <at> bernoul.li,  psainty <at> orcon.net.nz,  47800 <at> debbugs.gnu.org,
>   dario.gjorgjevski <at> gmail.com,  44128 <at> debbugs.gnu.org,  akrl <at> sdf.org
> Date: Sun, 18 Apr 2021 14:24:15 +0200
> 
> > But before you do anything else, please try the latest branch, where I
> > fixed some thinko.
> 
> That latest change fixed it for me.

Great, then I think we are good.  I just hope Jonas will be able to
test in his configuration as well.

Message #127 received at 47800 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Eli Zaretskii <eliz <at> gnu.org>, Phil Sainty <psainty <at> orcon.net.nz>
Cc: wilde <at> sha-bang.de, dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org,
 47800 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Mon, 19 Apr 2021 16:37:41 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: jonas <at> bernoul.li, wilde <at> sha-bang.de, 47800 <at> debbugs.gnu.org,
>>  dario.gjorgjevski <at> gmail.com, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
>> From: Phil Sainty <psainty <at> orcon.net.nz>
>> Date: Sun, 18 Apr 2021 03:00:17 +1200
>> 
>> On 18/04/21 2:29 am, Eli Zaretskii wrote:
>> > How about now?
>> 
>> This time it compiled; but with the following warnings, and
>> when I run it from the installed location (whether using the
>> absolute path or a symlink) I get a seg fault / core dump:
>
> Sorry about that.  Next try, please.

Now it works for me too.
Thanks!

Message #132 received at 47800-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 44128-done <at> debbugs.gnu.org, 47800-done <at> debbugs.gnu.org,
 psainty <at> orcon.net.nz, wilde <at> sha-bang.de, dario.gjorgjevski <at> gmail.com,
 akrl <at> sdf.org
Subject: Re: bug#47800: bug#44128: [feature/native-comp] When invoking a
 symlink to the 'emacs' binary Emacs fails to start
Date: Mon, 19 Apr 2021 17:52:02 +0300

> >> This time it compiled; but with the following warnings, and
> >> when I run it from the installed location (whether using the
> >> absolute path or a symlink) I get a seg fault / core dump:
> >
> > Sorry about that.  Next try, please.
> 
> Now it works for me too.
> Thanks!

Thanks, so I think we can close this issue now.  Thanks to everybody
who reported their results and tried my buggy code.

Previous Next

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