GNU bug report logs - #44128
[feature/native-comp]; When invoking a symlink to the 'emacs' binary Emacs fails to start

Previous Next

Full log

Message #28 received at 44128 <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, 44128 <at> debbugs.gnu.org, eli <at> gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: [feature/native-comp]
Date: Thu, 15 Apr 2021 15:29:36 +0300

> Cc: akrl <at> sdf.org, jonas <at> bernoul.li, 44128 <at> debbugs.gnu.org, eli <at> gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Fri, 16 Apr 2021 00:12:57 +1200
> 
> static char *
> real_filename (char *filename)
> {
>   char *real_name;
> #ifdef WINDOWSNT
>   /* w32_my_exename resolves symlinks internally, so no need to
>      call realpath.  */
>   real_name = xstrdup (filename);
> #else
>   real_name = realpath (filename, NULL);
>   if (!real_name)
>     fatal ("could not resolve realpath of \"%s\": %s",
> 	   filename, strerror (errno));
> #endif
>   return real_name;
> }
> 
> 
> 
> > What happens if you invoke it via a full absolute file name,
> > not relying on PATH?
> 
> That still works.

So the problem seems to be that real_filename is passed the literal
"emacs-native-comp", without the leading directories?  Why does that
happen? is it because the PATH search in load_pdump_find_executable
rejects symlinks?

Previous Next

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