bug#74383: 29.4; Emacs PGTK crashes on Void Linux

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

Hello,

I've been failing to get Emacs to launch under Sway on Void Linux, the
configuration I'm using was working fine on Arch Linux (using the same
Emacs version). Note that `emacs -Q' also segfaults, but `emacs -nw' is
able to launch emacs with all of my configuration without a single
warning.

You can find the backtrace leading up to this error in this paste:

  https://paste.sr.ht/~grtcdr/c39dad4913262557228d1158680f52613b728c6a

I tracked the issue down to a cairo_surface_create_similar_image() call
that results in the crash.

Before the program crashes, a warning about the "xpm" image type not
being supported is shown which may be relevant:

  (emacs:8670): GdkPixbuf-WARNING **: 13:38:44.606: Error loading XPM
  image loader: Image type “xpm” is not supported

In GNU Emacs 29.4 (build 2, x86_64-unknown-linux-musl, GTK+ Version
 3.24.43, cairo version 1.18.0) of 2024-10-13 built on
 void-buildbot-worker-musl
System Description: Void Linux

Configured using:
 'configure --with-pgtk --prefix=/usr --sysconfdir=/etc
 --sbindir=/usr/bin --bindir=/usr/bin --mandir=/usr/share/man
 --infodir=/usr/share/info --localstatedir=/var
 --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl
 '--libdir=${exec_prefix}/lib64' --with-file-notification=inotify
 --with-modules --with-jpeg --with-tiff --with-gif --with-png
 --with-webp --with-xpm --with-rsvg --without-imagemagick --with-xml2
 --with-gnutls --with-sound --with-m17n-flt --with-json --with-harfbuzz
 --with-cairo --with-libgmp --with-sqlite3 --with-tree-sitter
 --with-native-compilation=aot 'CFLAGS=-fno-PIE -mtune=generic -O2 -pipe
 -g -ffile-prefix-map=/builddir/emacs-29.4=.' 'CPPFLAGS= '
 'LDFLAGS=-no-pie -Wl,--as-needed ''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
WEBP XIM GTK3 ZLIB

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

Major mode: ERC

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  erc-networks-mode: t
  server-mode: t
  eros-mode: t
  which-key-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  global-corfu-mode: t
  corfu-mode: t
  marginalia-mode: t
  envrc-global-mode: t
  my/global-dired-omit-mode: t
  pixel-scroll-precision-mode: t
  delete-selection-mode: t
  auto-insert-mode: t
  electric-pair-mode: t
  savehist-mode: t
  repeat-mode: t
  global-auto-revert-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/grtcdr/.config/emacs/package/transient/lisp/transient hides /usr/share/emacs/29.4/lisp/transient
/home/grtcdr/.config/emacs/package/modus-themes/theme-loaddefs hides /usr/share/emacs/29.4/lisp/theme-loaddefs

Features:
(shadow sort mail-extr emacsbug term/screen magit-bookmark
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff
smerge-mode diff git-commit log-edit pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
shell magit-mode transient benchmark magit-git magit-base magit-section
dash network-stream epa-file url-http url-auth url-gw nsm erc-list
erc-menu erc-join erc-ring erc-pcomplete erc-track erc-match erc-button
erc-fill erc-stamp erc-netsplit my-erc erc-goodies erc erc-backend
erc-networks erc-common erc-compat erc-loaddefs tabify mule-util
orderless dired-aux cursor-sensor vertico-buffer term/xterm xterm
parse-time server exec-path-from-shell my-mode-line my-giornata
giornata-calendar iso8601 giornata giornata-lib my-engine my-email
notmuch notmuch-tree notmuch-jump notmuch-hello notmuch-show
notmuch-print notmuch-crypto notmuch-mua notmuch-message notmuch-draft
notmuch-maildir-fcc notmuch-address notmuch-company notmuch-parser
notmuch-wash coolj goto-addr icalendar diary-lib diary-loaddefs
notmuch-tag crm notmuch-lib notmuch-version notmuch-compat hl-line
mm-view mml-smime smime gnutls dig my-elfeed mpv tq org-timer org-clock
elfeed-show elfeed-search vc-git vc-dispatcher paredit edmacro kmacro
eros bookmark message sendmail yank-media rfc822 mml mml-sec epa derived
epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader shr text-property-search
pixel-fill kinsoku puny svg dom elfeed-csv elfeed elfeed-curl elfeed-log
elfeed-db elfeed-lib thingatpt url-queue url-file xml-query my-denote
my-cv cus-start org-protocol my-blog modus-operandi-theme modus-themes
org-agenda org-element org-persist org-id avl-tree generator org-refile
org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src
ob-comint org-pcomplete pcomplete comint ansi-osc org-list org-footnote
org-faces org-entities time-date noutline outline ob-emacs-lisp ob-core
ob-eval org-cycle org-table org-keys oc org-loaddefs find-func cal-menu
calendar cal-loaddefs ol org-fold org-fold-core org-compat org-version
org-macs format-spec dbus xml which-key vertico-multiform vertico corfu
marginalia envrc inheritenv diff-mode ansi-color easy-mmode dired-x
dired dired-loaddefs pixel-scroll cua-base ring delsel autoinsert
elec-pair savehist repeat autorevert filenotify auth-source-pass xdg
no-littering compat compat-30 jka-compr auto-compile yaml-mode-autoloads
yaml-autoloads with-editor-autoloads which-key-autoloads
vertico-autoloads treepy-autoloads transient-autoloads tempel-autoloads
s-autoloads rust-mode-autoloads rainbow-mode-autoloads paredit-autoloads
orderless-autoloads olivetti-autoloads no-littering-autoloads
mpv-autoloads modus-themes-autoloads markdown-mode-autoloads
marginalia-autoloads magit-autoloads lua-mode-autoloads logos-autoloads
llama-autoloads iwd-autoloads inheritenv-autoloads
graphviz-dot-mode-autoloads git-modes-autoloads giornata-autoloads
ghub-autoloads geiser-guile-autoloads geiser-autoloads forge-autoloads
f-autoloads exec-path-from-shell-autoloads eros-autoloads epkg-autoloads
envrc-autoloads emacsql-autoloads elfeed-autoloads
edit-indirect-autoloads denote-autoloads dash-autoloads corfu-autoloads
compat-autoloads closql-autoloads borg-autoloads avy-autoloads
auto-compile-autoloads auctex-autoloads borg loaddefs-gen lisp-mnt
radix-tree pcase info comp comp-cstr warnings rx cl-extra help-mode
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cus-edit pp cus-load icons wid-edit cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-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 nadvice seq simple cl-generic indonesian philippine
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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 494694 158548)
 (symbols 48 32975 0)
 (strings 32 150241 53925)
 (string-bytes 1 5640984)
 (vectors 16 69977)
 (vector-slots 8 1152542 171527)
 (floats 8 2999 1038)
 (intervals 56 3162 626)
 (buffers 984 21))

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Date: Sat, 16 Nov 2024 13:42:39 +0100
> 
> I've been failing to get Emacs to launch under Sway on Void Linux, the
> configuration I'm using was working fine on Arch Linux (using the same
> Emacs version). Note that `emacs -Q' also segfaults, but `emacs -nw' is
> able to launch emacs with all of my configuration without a single
> warning.
> 
> You can find the backtrace leading up to this error in this paste:
> 
>   https://paste.sr.ht/~grtcdr/c39dad4913262557228d1158680f52613b728c6a
> 
> I tracked the issue down to a cairo_surface_create_similar_image() call
> that results in the crash.
> 
> Before the program crashes, a warning about the "xpm" image type not
> being supported is shown which may be relevant:
> 
>   (emacs:8670): GdkPixbuf-WARNING **: 13:38:44.606: Error loading XPM
>   image loader: Image type “xpm” is not supported

Do you have the XPM library installed and available to Emacs?

Your build details indicate that Emacs was configured to be built with
XPM:

> Configured using:
>  'configure --with-pgtk --prefix=/usr --sysconfdir=/etc
>  --sbindir=/usr/bin --bindir=/usr/bin --mandir=/usr/share/man
>  --infodir=/usr/share/info --localstatedir=/var
>  --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl
>  '--libdir=${exec_prefix}/lib64' --with-file-notification=inotify
>  --with-modules --with-jpeg --with-tiff --with-gif --with-png
>  --with-webp --with-xpm --with-rsvg --without-imagemagick --with-xml2
               ^^^^^^^^^^
>  --with-gnutls --with-sound --with-m17n-flt --with-json --with-harfbuzz
>  --with-cairo --with-libgmp --with-sqlite3 --with-tree-sitter
>  --with-native-compilation=aot 'CFLAGS=-fno-PIE -mtune=generic -O2 -pipe
>  -g -ffile-prefix-map=/builddir/emacs-29.4=.' 'CPPFLAGS= '
>  'LDFLAGS=-no-pie -Wl,--as-needed ''

But the features actually available to Emacs don't include XPM:

> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
> LCMS2 LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
> RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
> WEBP XIM GTK3 ZLIB

So I wonder how this happened.

Did you build Emacs yourself, or was it installed from some distro?

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

> Do you have the XPM library installed and available to Emacs?

Yes, the package manager indicates I have the necessary package
installed:

    ~ $ xbps-query -Rs xpm
    [*] libXpm-3.5.17_1       X PixMap Library from modular Xorg X11

> But the features actually available to Emacs don't include XPM:
>
> So I wonder how this happened.
>
> Did you build Emacs yourself, or was it installed from some distro?

I used the officially packaged Void Linux "emacs-pgtk" package. Do you
think this is a packaging issue?

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: 74383@debbugs.gnu.org
> Date: Sat, 16 Nov 2024 19:01:06 +0100
> 
> > Do you have the XPM library installed and available to Emacs?
> 
> Yes, the package manager indicates I have the necessary package
> installed:
> 
>     ~ $ xbps-query -Rs xpm
>     [*] libXpm-3.5.17_1       X PixMap Library from modular Xorg X11

What does the below display (assuming it doesn't crash)?

  $ emacs -Q -batch --eval "(message \"%s\" (image-type-available-p 'xpm))"

> > But the features actually available to Emacs don't include XPM:
> >
> > So I wonder how this happened.
> >
> > Did you build Emacs yourself, or was it installed from some distro?
> 
> I used the officially packaged Void Linux "emacs-pgtk" package. Do you
> think this is a packaging issue?

Could be.  If the above command doesn't show "t", I would suggest to
take this up with the distro folks.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

> What does the below display (assuming it doesn't crash)?
>
>   $ emacs -Q -batch --eval "(message \"%s\" (image-type-available-p 'xpm))"

This returns "t", surprisingly.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: 74383@debbugs.gnu.org
> Date: Sat, 16 Nov 2024 21:15:26 +0100
> 
> > What does the below display (assuming it doesn't crash)?
> >
> >   $ emacs -Q -batch --eval "(message \"%s\" (image-type-available-p 'xpm))"
> 
> This returns "t", surprisingly.

Then I don't understand the error message you cited in your OP.
Perhaps it means that the problem is with GTK, not with Emacs per se.

So I'd still suggest to take this up with the distro folks.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

> Then I don't understand the error message you cited in your OP.
> Perhaps it means that the problem is with GTK, not with Emacs per se.

That was also very confusing for me.

> So I'd still suggest to take this up with the distro folks.

I'll do that, thanks for your time :)

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
>> Date: Sat, 16 Nov 2024 13:42:39 +0100
>> 
>> I've been failing to get Emacs to launch under Sway on Void Linux, the
>> configuration I'm using was working fine on Arch Linux (using the same
>> Emacs version). Note that `emacs -Q' also segfaults, but `emacs -nw' is
>> able to launch emacs with all of my configuration without a single
>> warning.
>> 
>> You can find the backtrace leading up to this error in this paste:
>> 
>>   https://paste.sr.ht/~grtcdr/c39dad4913262557228d1158680f52613b728c6a
>> 
>> I tracked the issue down to a cairo_surface_create_similar_image() call
>> that results in the crash.
>> 
>> Before the program crashes, a warning about the "xpm" image type not
>> being supported is shown which may be relevant:
>> 
>>   (emacs:8670): GdkPixbuf-WARNING **: 13:38:44.606: Error loading XPM
>>   image loader: Image type “xpm” is not supported
>
> Do you have the XPM library installed and available to Emacs?
>
> Your build details indicate that Emacs was configured to be built with
> XPM:
>
>> Configured using:
>>  'configure --with-pgtk --prefix=/usr --sysconfdir=/etc
>>  --sbindir=/usr/bin --bindir=/usr/bin --mandir=/usr/share/man
>>  --infodir=/usr/share/info --localstatedir=/var
>>  --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl
>>  '--libdir=${exec_prefix}/lib64' --with-file-notification=inotify
>>  --with-modules --with-jpeg --with-tiff --with-gif --with-png
>>  --with-webp --with-xpm --with-rsvg --without-imagemagick --with-xml2
>                ^^^^^^^^^^
>>  --with-gnutls --with-sound --with-m17n-flt --with-json --with-harfbuzz
>>  --with-cairo --with-libgmp --with-sqlite3 --with-tree-sitter
>>  --with-native-compilation=aot 'CFLAGS=-fno-PIE -mtune=generic -O2 -pipe
>>  -g -ffile-prefix-map=/builddir/emacs-29.4=.' 'CPPFLAGS= '
>>  'LDFLAGS=-no-pie -Wl,--as-needed ''
>
> But the features actually available to Emacs don't include XPM:
>
>> Configured features:
>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
>> LCMS2 LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
>> RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
>> WEBP XIM GTK3 ZLIB
>
> So I wonder how this happened.
>
> Did you build Emacs yourself, or was it installed from some distro?

The PGTK configuration always enables Emacs's built-in XPM library (in
image.c).

All the same, the OP's problem is that the gdk-pixbuf library invoked by
the toolkit to load tool-bar images no longer enables XPM support by
default, because, in their words, it was "not being used."  Someone must
volunteer to enable loading tool-bar images with Emacs's image system
instead.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>,  74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 08:12:39 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> >> Date: Sat, 16 Nov 2024 13:42:39 +0100
> >> 
> >> I've been failing to get Emacs to launch under Sway on Void Linux, the
> >> configuration I'm using was working fine on Arch Linux (using the same
> >> Emacs version). Note that `emacs -Q' also segfaults, but `emacs -nw' is
> >> able to launch emacs with all of my configuration without a single
> >> warning.
> >> 
> >> You can find the backtrace leading up to this error in this paste:
> >> 
> >>   https://paste.sr.ht/~grtcdr/c39dad4913262557228d1158680f52613b728c6a
> >> 
> >> I tracked the issue down to a cairo_surface_create_similar_image() call
> >> that results in the crash.
> >> 
> >> Before the program crashes, a warning about the "xpm" image type not
> >> being supported is shown which may be relevant:
> >> 
> >>   (emacs:8670): GdkPixbuf-WARNING **: 13:38:44.606: Error loading XPM
> >>   image loader: Image type “xpm” is not supported
> >
> > Do you have the XPM library installed and available to Emacs?
> >
> > Your build details indicate that Emacs was configured to be built with
> > XPM:
> >
> >> Configured using:
> >>  'configure --with-pgtk --prefix=/usr --sysconfdir=/etc
> >>  --sbindir=/usr/bin --bindir=/usr/bin --mandir=/usr/share/man
> >>  --infodir=/usr/share/info --localstatedir=/var
> >>  --host=x86_64-unknown-linux-musl --build=x86_64-unknown-linux-musl
> >>  '--libdir=${exec_prefix}/lib64' --with-file-notification=inotify
> >>  --with-modules --with-jpeg --with-tiff --with-gif --with-png
> >>  --with-webp --with-xpm --with-rsvg --without-imagemagick --with-xml2
> >                ^^^^^^^^^^
> >>  --with-gnutls --with-sound --with-m17n-flt --with-json --with-harfbuzz
> >>  --with-cairo --with-libgmp --with-sqlite3 --with-tree-sitter
> >>  --with-native-compilation=aot 'CFLAGS=-fno-PIE -mtune=generic -O2 -pipe
> >>  -g -ffile-prefix-map=/builddir/emacs-29.4=.' 'CPPFLAGS= '
> >>  'LDFLAGS=-no-pie -Wl,--as-needed ''
> >
> > But the features actually available to Emacs don't include XPM:
> >
> >> Configured features:
> >> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
> >> LCMS2 LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
> >> RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
> >> WEBP XIM GTK3 ZLIB
> >
> > So I wonder how this happened.
> >
> > Did you build Emacs yourself, or was it installed from some distro?
> 
> The PGTK configuration always enables Emacs's built-in XPM library (in
> image.c).
> 
> All the same, the OP's problem is that the gdk-pixbuf library invoked by
> the toolkit to load tool-bar images no longer enables XPM support by
> default, because, in their words, it was "not being used."  Someone must
> volunteer to enable loading tool-bar images with Emacs's image system
> instead.

Which GTK versions dropped XPM support?  We should probably reject
those versions at configure time, if they lead to Emacs that crashes
on startup.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Which GTK versions dropped XPM support?

I don't know.  I only learned of this fact this morning myself.

> We should probably reject those versions at configure time, if they
> lead to Emacs that crashes on startup.

It's not GTK that has deprecated XPM support, but a library it invokes
to load image files.  From what I've heard, it remains possible to
configure the library with XPM support.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Which GTK versions dropped XPM support?
>
> I don't know.  I only learned of this fact this morning myself.
>
>> We should probably reject those versions at configure time, if they
>> lead to Emacs that crashes on startup.
>
> It's not GTK that has deprecated XPM support, but a library it invokes
> to load image files.  From what I've heard, it remains possible to
> configure the library with XPM support.

Is it possible to gracefully crash or disable toolbar support when XPM
support is disabled?

There's gdk_pixbuf_format_is_disabled to check if a format is disabled.[1]

[1] https://docs.gtk.org/gdk-pixbuf/method.PixbufFormat.is_disabled.html

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Which GTK versions dropped XPM support?
>
> I don't know.  I only learned of this fact this morning myself.
>
>> We should probably reject those versions at configure time, if they
>> lead to Emacs that crashes on startup.
>
> It's not GTK that has deprecated XPM support, but a library it invokes
> to load image files.  From what I've heard, it remains possible to
> configure the library with XPM support.

Is it possible to gracefully crash or disable toolbar support when XPM
support is disabled?

There's gdk_pixbuf_format_is_disabled to check if a format is disabled.[1]

[1] https://docs.gtk.org/gdk-pixbuf/method.PixbufFormat.is_disabled.html

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

> All the same, the OP's problem is that the gdk-pixbuf library invoked by
> the toolkit to load tool-bar images no longer enables XPM support by
> default, because, in their words, it was "not being used."  Someone must
> volunteer to enable loading tool-bar images with Emacs's image system
> instead.

I should have probably mentioned that my early initialization file
disables the toolbar along with other visual elements, so it's odd that
these images would get created at all.

I assume they're created eagerly so it makes no difference whether or
not the toolbar is disabled.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 12:40:57 +0100
> 
> > All the same, the OP's problem is that the gdk-pixbuf library invoked by
> > the toolkit to load tool-bar images no longer enables XPM support by
> > default, because, in their words, it was "not being used."  Someone must
> > volunteer to enable loading tool-bar images with Emacs's image system
> > instead.
> 
> I should have probably mentioned that my early initialization file
> disables the toolbar along with other visual elements, so it's odd that
> these images would get created at all.
> 
> I assume they're created eagerly so it makes no difference whether or
> not the toolbar is disabled.

Maybe you should disable it in your ~/.emacs.d/gtkrc?  Or is that
~/.themes/THEME/gtk-3.0/gtk.css now?

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
>> Cc: 74383@debbugs.gnu.org
>> Date: Sun, 17 Nov 2024 12:40:57 +0100
>> 
>> > All the same, the OP's problem is that the gdk-pixbuf library invoked by
>> > the toolkit to load tool-bar images no longer enables XPM support by
>> > default, because, in their words, it was "not being used."  Someone must
>> > volunteer to enable loading tool-bar images with Emacs's image system
>> > instead.
>> 
>> I should have probably mentioned that my early initialization file
>> disables the toolbar along with other visual elements, so it's odd that
>> these images would get created at all.
>> 
>> I assume they're created eagerly so it makes no difference whether or
>> not the toolbar is disabled.
>
> Maybe you should disable it in your ~/.emacs.d/gtkrc?  Or is that
> ~/.themes/THEME/gtk-3.0/gtk.css now?

I'm not sure what to put there. The manual entry [1] for GTK styling
links to a dead resource [2] concerning the GTK styling options. I
suppose it means to reference this page
<https://docs.gtk.org/gtk3/css-overview.html>

Still, that page doesn't say anything about toolbars.

I found this answer [3] which uses "gsettings" and as far as I know,
settings changed through gsettings do not affect Emacs, so I have to
create a stylesheet just as the manual says.

Any pointers?

[1]: https://www.gnu.org/software/emacs/manual/html_node/emacs/GTK-resources.html
[2]: https://developer-old.gnome.org/gtk3/3.0/GtkCssProvider.html
[3]: https://askubuntu.com/a/359049

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 13:23:43 +0100
> 
> I found this answer [3] which uses "gsettings" and as far as I know,
> settings changed through gsettings do not affect Emacs, so I have to
> create a stylesheet just as the manual says.
> 
> Any pointers?

See src/xsettings.c, I hope this is relevant to your case (but I know
nothing about GTK, so apologies if this makes no sense).

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
>> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
>> Date: Sun, 17 Nov 2024 13:23:43 +0100
>> 
>> I found this answer [3] which uses "gsettings" and as far as I know,
>> settings changed through gsettings do not affect Emacs, so I have to
>> create a stylesheet just as the manual says.
>> 
>> Any pointers?
>
> See src/xsettings.c, I hope this is relevant to your case (but I know
> nothing about GTK, so apologies if this makes no sense).

It's very relevant and the source code is actually really insightful.

Line 219:

   #ifdef HAVE_GSETTINGS
   #define GSETTINGS_SCHEMA         "org.gnome.desktop.interface"
   #define GSETTINGS_TOOL_BAR_STYLE "toolbar-style"

Well, according to `system-configuration-features', gsettings is configured:

"ACL ... GSETTINGS HARFBUZZ ..."

So GSETTINGS is indeed considered, let's see the value of my setting
outside of Emacs:

   $ gsettings get org.gnome.desktop.interface toolbar-style
   => 'text'

According to https://docs.gtk.org/gtk3/enum.ToolbarStyle.html, the
"text" style corresponds to the value "1".

Line 1080-1088:

    val = g_settings_get_value (gsettings_client, GSETTINGS_TOOL_BAR_STYLE);
      if (val)
        {
          g_variant_ref_sink (val);
          if (g_variant_is_of_type (val, G_VARIANT_TYPE_STRING))
            current_tool_bar_style
              = map_tool_bar_style (g_variant_get_string (val, NULL));
          g_variant_unref (val);
        }

Okay, but `(tool-bar-get-system-style)' actually returns "image"... huh?

Docstring says "image" is the fallback return value... Why is the
mapping not being handled correctly?

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

> Docstring says "image" is the fallback return value... Why is the
> mapping not being handled correctly?

I added the following bit of configuration to the top of my
early-init.el and it also made no difference.

  (setq tool-bar-style "text")

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 14:15:43 +0100
> 
> > Docstring says "image" is the fallback return value... Why is the
> > mapping not being handled correctly?
> 
> I added the following bit of configuration to the top of my
> early-init.el and it also made no difference.
> 
>   (setq tool-bar-style "text")

I hope Po Lu will be able to help you out.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 14:15:43 +0100
> 
> > Docstring says "image" is the fallback return value... Why is the
> > mapping not being handled correctly?
> 
> I added the following bit of configuration to the top of my
> early-init.el and it also made no difference.
> 
>   (setq tool-bar-style "text")

Just by looking at the code, it looks like the value of tool-bar-style
is supposed to be a symbol, not a string.  So try this instead:

  (setq tool-bar-style 'text)

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
>> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
>> Date: Sun, 17 Nov 2024 14:15:43 +0100
>> 
>> > Docstring says "image" is the fallback return value... Why is the
>> > mapping not being handled correctly?
>> 
>> I added the following bit of configuration to the top of my
>> early-init.el and it also made no difference.
>> 
>>   (setq tool-bar-style "text")

> Just by looking at the code, it looks like the value of tool-bar-style
> is supposed to be a symbol, not a string.  So try this instead:
>
>   (setq tool-bar-style 'text)

Yeah, I should have paid closer attention to the `EQ' there. I've
changed it now.

Unfortunately, Emacs is still crashing even with the correct symbol
value set as the very first line in early-init.el.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Taha Aziz Ben Ali]

I don't know how to say this but... the issue resolved itself (?).

I did a lot of tweaking today and installed a whole lot of stuff as I've
only settled into this distribution, so perhaps some essential library
(?) was installed and Emacs got all happy and started just fine.

I've tried removing some of the packages I installed to determine what
exactly caused Emacs to mysteriously work. Nothing yet. I don't think
I'll be able to find out either.

I appreciate everyone's time and especially all the effort to help me
out.

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

> From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 18:34:56 +0100
> 
> I don't know how to say this but... the issue resolved itself (?).
> 
> I did a lot of tweaking today and installed a whole lot of stuff as I've
> only settled into this distribution, so perhaps some essential library
> (?) was installed and Emacs got all happy and started just fine.
> 
> I've tried removing some of the packages I installed to determine what
> exactly caused Emacs to mysteriously work. Nothing yet. I don't think
> I'll be able to find out either.
> 
> I appreciate everyone's time and especially all the effort to help me
> out.

Thanks for telling us.

Po Lu, is there something here we should add to PROBLEMS, perhaps?

bug#74383: 29.4; Emacs PGTK crashes on Void Linux

[Eli Zaretskii]

Ping!

> Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> Date: Sun, 17 Nov 2024 19:40:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Taha Aziz Ben Ali <ba.tahaaziz@gmail.com>
> > Cc: luangruo@yahoo.com, 74383@debbugs.gnu.org
> > Date: Sun, 17 Nov 2024 18:34:56 +0100
> > 
> > I don't know how to say this but... the issue resolved itself (?).
> > 
> > I did a lot of tweaking today and installed a whole lot of stuff as I've
> > only settled into this distribution, so perhaps some essential library
> > (?) was installed and Emacs got all happy and started just fine.
> > 
> > I've tried removing some of the packages I installed to determine what
> > exactly caused Emacs to mysteriously work. Nothing yet. I don't think
> > I'll be able to find out either.
> > 
> > I appreciate everyone's time and especially all the effort to help me
> > out.
> 
> Thanks for telling us.
> 
> Po Lu, is there something here we should add to PROBLEMS, perhaps?
> 
> 
> 
>