bug#49864: 28.0.50; Fails to start after "make install"

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]

Emacs starts normally when I run it directly from the /src folder, but
fails to start when starting from the installation directory
"/usr/local/bin/emacs"

This only happens with native-compilation.

Steps I followed:
git clone git://git.sv.gnu.org/emacs.git --depth 1
cd emacs
./autogen.sh
./configure --with-mailutils --with-native-compilation
sudo make install
src/emacs -Q -> works as expected
emacs -Q ->
Error using execdir
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/:
emacs:
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln:
cannot open shared object file: No such file or directory

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4)
 of 2021-08-03 built on iloveyou
Repository revision: 88577aed3a17109bb7b13871f185133641c25e73
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Arch Linux

Configured using:
 'configure --with-mailutils --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 67036 9106)
 (symbols 48 6615 0)
 (strings 32 19283 1673)
 (string-bytes 1 655196)
 (vectors 16 13450)
 (vector-slots 8 287066 12589)
 (floats 8 22 31)
 (intervals 56 199 0)
 (buffers 992 10))

[-- Attachment #2: Type: text/html, Size: 4103 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Wed, 4 Aug 2021 07:42:06 +0200
> 
> ./autogen.sh
> ./configure --with-mailutils --with-native-compilation
> sudo make install
> src/emacs -Q -> works as expected
> emacs -Q ->
> Error using execdir /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/:
> emacs:
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln:
> cannot open shared object file: No such file or directory

Could it be that the emacs.pdmp file is installed in the wrong place,
and that confuses Emacs at startup?  The emacs.pdmp file should be in
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/

And where do you have the file window-0d1b8b93-dcb2375f.eln there? on
your system? can you show the full absolute file names of all of its
copies you have?

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

From a clean environment and emacs install the window and emacs.pdmp files
are at the following locations

/home/wilhelm/src/tools/emacs/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
/usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln

/home/wilhelm/src/tools/emacs/src/emacs.pdmp
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp

evaluating the relative pathing, it ends up at
/usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln

the same install process worked about 2 months ago, so I can possibly try
to find the commit where it still worked

On Wed, Aug 4, 2021 at 1:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Wed, 4 Aug 2021 07:42:06 +0200
> >
> > ./autogen.sh
> > ./configure --with-mailutils --with-native-compilation
> > sudo make install
> > src/emacs -Q -> works as expected
> > emacs -Q ->
> > Error using execdir
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/:
> > emacs:
> >
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln:
> > cannot open shared object file: No such file or directory
>
> Could it be that the emacs.pdmp file is installed in the wrong place,
> and that confuses Emacs at startup?  The emacs.pdmp file should be in
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/
>
> And where do you have the file window-0d1b8b93-dcb2375f.eln there? on
> your system? can you show the full absolute file names of all of its
> copies you have?
>

[-- Attachment #2: Type: text/html, Size: 2170 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 08:42:55 +0200
> Cc: 49864@debbugs.gnu.org
> 
> From a clean environment and emacs install the window and emacs.pdmp files are at the following locations
> 
> /home/wilhelm/src/tools/emacs/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> /usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> 
> /home/wilhelm/src/tools/emacs/src/emacs.pdmp
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp

This looks correct.  But is there another *.pdmp file somewhere on
your system, like in /usr/local/bin/, where the Emacs executable file
is installed?

> evaluating the relative pathing, it ends up at
> /usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln

I don't think I follow: what do you mean by "evaluating the relative
pathing"?

Alos, are any of the files/directories involved in this hard or
symbolic links? if so, can you show where each link points, i.e. the
real target files/directories of each link?

> the same install process worked about 2 months ago, so I can possibly try to find the commit where it still
> worked

If the above doesn't give any clues, maybe we should find such a
commit.  But I would prefer first to understand better what happens
with the current master branch.

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

These are all the *.pdmp files on my system:
/home/wilhelm/src/tools/emacs/src/bootstrap-emacs.pdmp
/home/wilhelm/src/tools/emacs/src/emacs-28.0.50.1.pdmp
/home/wilhelm/src/tools/emacs/src/emacs.pdmp
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp

The relative path comment was unimportant, sorry about that. I just meant
that emacs is trying to find
`/usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln`
which does not exist.

From what I can see these are the only links:
/usr/local/bin/emacs -> emacs-28.0.50
/home/wilhelm/src/tools/otp/lib/tools/emacs/tags.erl -> ../src/tags.erl

The only non-standard configuration is umask set to 0077, but not sure if
that is relevant.

On Thu, Aug 5, 2021 at 8:51 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Thu, 5 Aug 2021 08:42:55 +0200
> > Cc: 49864@debbugs.gnu.org
> >
> > From a clean environment and emacs install the window and emacs.pdmp
> files are at the following locations
> >
> >
> /home/wilhelm/src/tools/emacs/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> >
> /usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> >
> > /home/wilhelm/src/tools/emacs/src/emacs.pdmp
> > /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp
>
> This looks correct.  But is there another *.pdmp file somewhere on
> your system, like in /usr/local/bin/, where the Emacs executable file
> is installed?
>
> > evaluating the relative pathing, it ends up at
> >
> /usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
>
> I don't think I follow: what do you mean by "evaluating the relative
> pathing"?
>
> Alos, are any of the files/directories involved in this hard or
> symbolic links? if so, can you show where each link points, i.e. the
> real target files/directories of each link?
>
> > the same install process worked about 2 months ago, so I can possibly
> try to find the commit where it still
> > worked
>
> If the above doesn't give any clues, maybe we should find such a
> commit.  But I would prefer first to understand better what happens
> with the current master branch.
>

[-- Attachment #2: Type: text/html, Size: 3055 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 09:02:48 +0200
> Cc: 49864@debbugs.gnu.org
> 
> These are all the *.pdmp files on my system:
> /home/wilhelm/src/tools/emacs/src/bootstrap-emacs.pdmp
> /home/wilhelm/src/tools/emacs/src/emacs-28.0.50.1.pdmp
> /home/wilhelm/src/tools/emacs/src/emacs.pdmp
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp
> 
> The relative path comment was unimportant, sorry about that. I just meant that emacs is trying to find
> `/usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln` which does not exist. 
> 
> From what I can see these are the only links:
> /usr/local/bin/emacs -> emacs-28.0.50
> /home/wilhelm/src/tools/otp/lib/tools/emacs/tags.erl -> ../src/tags.erl

Hmm... we are missing something here.

Can you start Emacs under GDB and step through the code I will point
out, so that we could collect more information about what happens?  If
you can, I will provide detailed instructions.

Thanks.

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Yes, of course, but I will only be able to do it a bit later today. I am
not too familiar with GDB though.

On Thu, Aug 5, 2021 at 9:09 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Thu, 5 Aug 2021 09:02:48 +0200
> > Cc: 49864@debbugs.gnu.org
> >
> > These are all the *.pdmp files on my system:
> > /home/wilhelm/src/tools/emacs/src/bootstrap-emacs.pdmp
> > /home/wilhelm/src/tools/emacs/src/emacs-28.0.50.1.pdmp
> > /home/wilhelm/src/tools/emacs/src/emacs.pdmp
> > /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/emacs.pdmp
> >
> > The relative path comment was unimportant, sorry about that. I just
> meant that emacs is trying to find
> >
> `/usr/local/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln`
> which does not exist.
> >
> > From what I can see these are the only links:
> > /usr/local/bin/emacs -> emacs-28.0.50
> > /home/wilhelm/src/tools/otp/lib/tools/emacs/tags.erl -> ../src/tags.erl
>
> Hmm... we are missing something here.
>
> Can you start Emacs under GDB and step through the code I will point
> out, so that we could collect more information about what happens?  If
> you can, I will provide detailed instructions.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 09:14:10 +0200
> Cc: 49864@debbugs.gnu.org
> 
> Yes, of course, but I will only be able to do it a bit later today. I am not too familiar with GDB though. 

Thanks.  The instructions are below:

  $ cd /home/wilhelm/src/tools/emacs/src
  $ gdb /usr/local/bin/emacs-28.0.50
  ...
  (gdb) source ./.gdbinit
  (gdb) break pdumper.c:5315
  (gdb) r -Q

When GDB announces that the breakpoint at pdumper.c:5315 breaks, do
this:

  (gdb) p cu_file1
  (gdb) xstring
  (gdb) p cu_file2
  (gdb) xstring

and show the results of these commands.  Then step through the code,
one line at a time, with the "n" ("next") command.  Eventually, you
should get to line 5321:

  5321                if (file_access_p (fndata, F_OK))

Then show the value of fndata, which should be a file name:

  (gdb) p fndata

Type "next" again.  If the file_access_p call fails (returns 'false'),
show the value of errno immediately after stepping past the line that
calls file_access_p:

  (gdb) p errno

In that case (if file_access_p fails), the "next" command will land
you in this block:

	    else
	      {
		eln_fname = make_uninit_string (execdir_len + fn2_len);
		fndata = SSDATA (eln_fname);
		memcpy (fndata, emacs_execdir, execdir_len);
		memcpy (fndata + execdir_len, SSDATA (cu_file2), fn2_len);
		installation_state = LOCAL_BUILD;
	      }

Please type "n" ("next") repeatedly until you get to the last line,
which starts with "installation_state =", and show the value of
fndata:

  (gdb) p fndata

Finally, keep stepping with "n" until you come to this line:

	comp_u->handle = dynlib_open (SSDATA (eln_fname));

and type the following commands:

  (gdb) p eln_fname
  (gdb) xstring

and show their results.

You can then terminate the GDB session:

  (gdb) q

(Answer "y" if it asks whether to quit.)

I hope the data you collect and report will explain what happens, or
at least give us a direction in which to look for the explanation.

Thanks again for your help in this matter.

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 6631 bytes --]

It did not go exactly as the above, but adding the whole log here in case
it helps, as I am not 100% sure if I did it correctly; will go over it
again later in today.

~/src/tools/emacs/src $ gdb /usr/local/bin/emacs-28.0.50
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/emacs-28.0.50...
warning: File "/home/wilhelm/src/tools/emacs/src/.gdbinit" auto-loading has
been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /home/wilhelm/src/tools/emacs/src/.gdbinit
line to your configuration file "/home/wilhelm/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/wilhelm/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the
shell:
info "(gdb)Auto-loading safe path"
(gdb) source ./.gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :0.0
TERM = xterm-256color
Breakpoint 1 at 0x4766c: file emacs.c, line 399.
Breakpoint 2 at 0x105420: file xterm.c, line 10258.
(gdb) break pdumper.c:5315
Breakpoint 3 at 0x19959d: file pdumper.c, line 5315.
(gdb) r -Q
Starting program: /usr/local/bin/emacs-28.0.50 -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 3, dump_do_dump_relocation (dump_base=<optimized out>,
reloc=...) at pdumper.c:5315
5315 if (installation_state == UNKNOWN)
(gdb) p cu_file1
$1 = XIL(0x7ffff08e4bac)
(gdb) xstring
$2 = (struct Lisp_String *) 0x7ffff08e4ba8
"../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln"
(gdb) p cu_file2
$3 = XIL(0x7ffff08e4b8c)
(gdb) xstring
$4 = (struct Lisp_String *) 0x7ffff08e4b88
"../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln"
(gdb) n
5317    eln_fname = make_uninit_string (execdir_len + fn1_len);
(gdb) n
5318    fndata = SSDATA (eln_fname);
(gdb) n
5319    memcpy (fndata, emacs_execdir, execdir_len);
(gdb) n
1561  return XSTRING (string)->u.s.data;
(gdb) n
5321    if (file_access_p (fndata, F_OK))
(gdb) p fndata
$5 = <optimized out>
(gdb) next
5325 eln_fname = make_uninit_string (execdir_len + fn2_len);
(gdb) p errno
'errno' has unknown type; cast it to its declared type
(gdb) n
5326 fndata = SSDATA (eln_fname);
(gdb) n
5327 memcpy (fndata, emacs_execdir, execdir_len);
(gdb) n
1561  return XSTRING (string)->u.s.data;
(gdb) n
5329 installation_state = LOCAL_BUILD;
(gdb) p fndata
$6 = <optimized out>
(gdb) n
5331    fixup_eln_load_path (eln_fname);
(gdb) n
5352 comp_u->file = eln_fname;
(gdb) p eln_fname
$7 = XIL(0x555555c2bcb4)
(gdb) xstring
$8 = (struct Lisp_String *) 0x555555c2bcb0
"/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln"
(gdb) n
1561  return XSTRING (string)->u.s.data;
(gdb) n
5354 if (!comp_u->handle)
(gdb) n
5356    fprintf (stderr, "Error using execdir %s:\n",
(gdb) n
Error using execdir
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/:
5358    error ("%s", dynlib_error ());
(gdb) p errno
'errno' has unknown type; cast it to its declared type
(gdb) n
emacs:
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln:
cannot open shared object file: No such file or directory
[Inferior 1 (process 4129) exited with code 01]
(gdb) q

On Thu, Aug 5, 2021 at 9:59 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Thu, 5 Aug 2021 09:14:10 +0200
> > Cc: 49864@debbugs.gnu.org
> >
> > Yes, of course, but I will only be able to do it a bit later today. I am
> not too familiar with GDB though.
>
> Thanks.  The instructions are below:
>
>   $ cd /home/wilhelm/src/tools/emacs/src
>   $ gdb /usr/local/bin/emacs-28.0.50
>   ...
>   (gdb) source ./.gdbinit
>   (gdb) break pdumper.c:5315
>   (gdb) r -Q
>
> When GDB announces that the breakpoint at pdumper.c:5315 breaks, do
> this:
>
>   (gdb) p cu_file1
>   (gdb) xstring
>   (gdb) p cu_file2
>   (gdb) xstring
>
> and show the results of these commands.  Then step through the code,
> one line at a time, with the "n" ("next") command.  Eventually, you
> should get to line 5321:
>
>   5321                if (file_access_p (fndata, F_OK))
>
> Then show the value of fndata, which should be a file name:
>
>   (gdb) p fndata
>
> Type "next" again.  If the file_access_p call fails (returns 'false'),
> show the value of errno immediately after stepping past the line that
> calls file_access_p:
>
>   (gdb) p errno
>
> In that case (if file_access_p fails), the "next" command will land
> you in this block:
>
>             else
>               {
>                 eln_fname = make_uninit_string (execdir_len + fn2_len);
>                 fndata = SSDATA (eln_fname);
>                 memcpy (fndata, emacs_execdir, execdir_len);
>                 memcpy (fndata + execdir_len, SSDATA (cu_file2), fn2_len);
>                 installation_state = LOCAL_BUILD;
>               }
>
> Please type "n" ("next") repeatedly until you get to the last line,
> which starts with "installation_state =", and show the value of
> fndata:
>
>   (gdb) p fndata
>
> Finally, keep stepping with "n" until you come to this line:
>
>         comp_u->handle = dynlib_open (SSDATA (eln_fname));
>
> and type the following commands:
>
>   (gdb) p eln_fname
>   (gdb) xstring
>
> and show their results.
>
> You can then terminate the GDB session:
>
>   (gdb) q
>
> (Answer "y" if it asks whether to quit.)
>
> I hope the data you collect and report will explain what happens, or
> at least give us a direction in which to look for the explanation.
>
> Thanks again for your help in this matter.
>

[-- Attachment #2: Type: text/html, Size: 8316 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 14:44:00 +0200
> Cc: 49864@debbugs.gnu.org
> 
> 5321    if (file_access_p (fndata, F_OK))
> (gdb) p fndata
> $5 = <optimized out>
> (gdb) next

Here, instead of "next", please say "step" to step into
file_access_p.  Then you should see something like this:

  (gdb) step
  file_access_p (file=0x67e768c "/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln", amode=0) at fileio.c:162
  162       if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)

That shows the file name it is trying to access in the list of
arguments of the function.  As far as I understand from the other
information you posted, that file does exist on your system, is that
right?  Because you said the file below does exist:

  /usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln

But for some reason, the faccessat call fails.  We need to understand
why.

> (gdb) p errno
> 'errno' has unknown type; cast it to its declared type

To work around the problem with errno's type, try this:

  (gdb) p (int)errno

The value of errno will hopefully tell us what's wrong.  I'm guessing
it's some problem with accessing those files, perhaps related to the
value of umask you reported.

Thanks.

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> Date: Thu, 05 Aug 2021 16:33:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 49864@debbugs.gnu.org
> 
>   162       if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
> 
> That shows the file name it is trying to access in the list of
> arguments of the function.  As far as I understand from the other
> information you posted, that file does exist on your system, is that
> right?  Because you said the file below does exist:
> 
>   /usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> 
> But for some reason, the faccessat call fails.  We need to understand
> why.
> 
> > (gdb) p errno
> > 'errno' has unknown type; cast it to its declared type
> 
> To work around the problem with errno's type, try this:
> 
>   (gdb) p (int)errno

To clarify: please print the value of errno as above _after_ stepping
over the call to faccessat, i.e. when GDB shows this:

  162       if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
  (gdb) next
  175       return false;

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

Thanks for your patience, I appreciate the effort trying to solve this.

Here is the gdb log:
1561  return XSTRING (string)->u.s.data;
(gdb) n
5321    if (file_access_p (fndata, F_OK))
(gdb) step
file_access_p (
    file=file@entry=0x555555cf8838
"/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln",
amode=amode@entry=0) at fileio.c:162
162  if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
(gdb) next
dump_do_dump_relocation (dump_base=<optimized out>, reloc=...) at
pdumper.c:5325
5325 eln_fname = make_uninit_string (execdir_len + fn2_len);
(gdb) p (int)errno
$1 = 13

I can indeed access
/usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
but only as root. Which seems wrong. I can start emacs as sudo ( have not
even checked this before )

Which is then probably a umask issue as this folder's permission seems
wrong:
 /usr/local/lib $ sudo ls -lah emacs
total 12K
drwx------ 3 root root 4.0K Aug  3 23:00 .
drwxr-xr-x 4 root root 4.0K Aug  3 23:00 ..
drwx------ 3 root root 4.0K Aug  3 23:00 28.0.50

sudo ls -lah emacs/28.0.50
total 12K
drwx------ 3 root root 4.0K Aug  3 23:00 .
drwx------ 3 root root 4.0K Aug  3 23:00 ..
drwx------ 3 root root 4.0K Aug  3 23:00 native-lisp

Yes the file exists, but I cannot access it as a non-root ( should have
checked before ). I can remove the folder and re-install and the permission
is the same as above.


On Thu, Aug 5, 2021 at 4:04 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 05 Aug 2021 16:33:53 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 49864@debbugs.gnu.org
> >
> >   162       if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
> >
> > That shows the file name it is trying to access in the list of
> > arguments of the function.  As far as I understand from the other
> > information you posted, that file does exist on your system, is that
> > right?  Because you said the file below does exist:
> >
> >
>  /usr/local/lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> >
> > But for some reason, the faccessat call fails.  We need to understand
> > why.
> >
> > > (gdb) p errno
> > > 'errno' has unknown type; cast it to its declared type
> >
> > To work around the problem with errno's type, try this:
> >
> >   (gdb) p (int)errno
>
> To clarify: please print the value of errno as above _after_ stepping
> over the call to faccessat, i.e. when GDB shows this:
>
>   162       if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
>   (gdb) next
>   175       return false;
>

[-- Attachment #2: Type: text/html, Size: 3558 bytes --]

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 17:21:36 +0200
> Cc: 49864@debbugs.gnu.org
> 
> 162  if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
> (gdb) next
> dump_do_dump_relocation (dump_base=<optimized out>, reloc=...) at pdumper.c:5325
> 5325 eln_fname = make_uninit_string (execdir_len + fn2_len);
> (gdb) p (int)errno
> $1 = 13
> 
> I can indeed access
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> but only as root. Which seems wrong. I can start emacs as sudo ( have not even checked this before )
> 
> Which is then probably a umask issue as this folder's permission seems wrong:
>  /usr/local/lib $ sudo ls -lah emacs
> total 12K
> drwx------ 3 root root 4.0K Aug  3 23:00 .
> drwxr-xr-x 4 root root 4.0K Aug  3 23:00 ..
> drwx------ 3 root root 4.0K Aug  3 23:00 28.0.50
> 
> sudo ls -lah emacs/28.0.50
> total 12K
> drwx------ 3 root root 4.0K Aug  3 23:00 .
> drwx------ 3 root root 4.0K Aug  3 23:00 ..
> drwx------ 3 root root 4.0K Aug  3 23:00 native-lisp
> 
> Yes the file exists, but I cannot access it as a non-root ( should have checked before ). I can remove the
> folder and re-install and the permission is the same as above. 

So this sounds like some problem with how "make install" sets
permissions on directories on your system: it ends up disallowing your
user access to those files.  Or maybe you should follow "make install"
by a suitable chmod command, to make those files accessible?

I don't know enough about sudo to help you more, but maybe someone
else here does?  The main question to answer, from my POV, is whether
this is something we could address in our "make install", or something
only you can fix on your system.

Thanks.

bug#49864: 28.0.50; Fails to start after "make install"

[Wilhelm Kirschbaum]

[-- Attachment #1.1: Type: text/plain, Size: 2470 bytes --]

The patch I attached fixes the install issue for me without any other
modification. This patch also seems to be consistent with other MKDIR_P
commands in the Makefile.

 ### Install native compiled Lisp files.
 install-eln: lisp
 ifeq ($(HAVE_NATIVE_COMP),yes)
- find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
+ umask 022; find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}"
\; ; \
  find native-lisp -type f -exec ${INSTALL_DATA} "{}" "$(ELN_DESTDIR){}" \;




On Thu, Aug 5, 2021 at 6:29 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> > Date: Thu, 5 Aug 2021 17:21:36 +0200
> > Cc: 49864@debbugs.gnu.org
> >
> > 162  if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
> > (gdb) next
> > dump_do_dump_relocation (dump_base=<optimized out>, reloc=...) at
> pdumper.c:5325
> > 5325 eln_fname = make_uninit_string (execdir_len + fn2_len);
> > (gdb) p (int)errno
> > $1 = 13
> >
> > I can indeed access
> >
> /usr/local/libexec/emacs/28.0.50/x86_64-pc-linux-gnu/../../../../bin/../lib/emacs/28.0.50/native-lisp/28.0.50-864bf4e5/preloaded/window-0d1b8b93-dcb2375f.eln
> > but only as root. Which seems wrong. I can start emacs as sudo ( have
> not even checked this before )
> >
> > Which is then probably a umask issue as this folder's permission seems
> wrong:
> >  /usr/local/lib $ sudo ls -lah emacs
> > total 12K
> > drwx------ 3 root root 4.0K Aug  3 23:00 .
> > drwxr-xr-x 4 root root 4.0K Aug  3 23:00 ..
> > drwx------ 3 root root 4.0K Aug  3 23:00 28.0.50
> >
> > sudo ls -lah emacs/28.0.50
> > total 12K
> > drwx------ 3 root root 4.0K Aug  3 23:00 .
> > drwx------ 3 root root 4.0K Aug  3 23:00 ..
> > drwx------ 3 root root 4.0K Aug  3 23:00 native-lisp
> >
> > Yes the file exists, but I cannot access it as a non-root ( should have
> checked before ). I can remove the
> > folder and re-install and the permission is the same as above.
>
> So this sounds like some problem with how "make install" sets
> permissions on directories on your system: it ends up disallowing your
> user access to those files.  Or maybe you should follow "make install"
> by a suitable chmod command, to make those files accessible?
>
> I don't know enough about sudo to help you more, but maybe someone
> else here does?  The main question to answer, from my POV, is whether
> this is something we could address in our "make install", or something
> only you can fix on your system.
>
> Thanks.
>

[-- Attachment #1.2: Type: text/html, Size: 3263 bytes --]

[-- Attachment #2: specify-native-lisp-create-dir-umask.patch --]
[-- Type: text/x-patch, Size: 466 bytes --]

diff --git a/Makefile.in b/Makefile.in
index 97d954b..39808df 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -789,7 +789,7 @@ install-etc:
 ### Install native compiled Lisp files.
 install-eln: lisp
 ifeq ($(HAVE_NATIVE_COMP),yes)
-	find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
+	umask 022; find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
 	find native-lisp -type f -exec ${INSTALL_DATA} "{}" "$(ELN_DESTDIR){}" \;
 endif
 

bug#49864: 28.0.50; Fails to start after "make install"

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Date: Thu, 5 Aug 2021 20:27:06 +0200
> Cc: 49864@debbugs.gnu.org
> 
> The patch I attached fixes the install issue for me without any other modification. This patch also seems to
> be consistent with other MKDIR_P commands in the Makefile.
> 
>  ### Install native compiled Lisp files.
>  install-eln: lisp
>  ifeq ($(HAVE_NATIVE_COMP),yes)
> - find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
> + umask 022; find native-lisp -type d -exec $(MKDIR_P) "$(ELN_DESTDIR){}" \; ; \
>   find native-lisp -type f -exec ${INSTALL_DATA} "{}" "$(ELN_DESTDIR){}" \;

Thanks, I installed such a change, and I'm closing this bug report.