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

Previous Next

Package: emacs;

Reported by: Jonas Bernoulli <jonas <at> bernoul.li>

Date: Wed, 21 Oct 2020 22:00:02 UTC

Severity: normal

Merged with 47801

Found in version 28.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: 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?




This bug report was last modified 4 years and 32 days ago.

Previous Next


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