bug#75018: 30.0.93; Dired icon missing in tool-bar

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 22 Dec 2024 09:32:23 -0600
> From: "john muhl" <jm@pub.pink>
> Cc: 75018@debbugs.gnu.org
> 
> On Sun, Dec 22, 2024, at 12:43 AM, Eli Zaretskii wrote:
> >> From: john muhl <jm@pub.pink>
> >> Date: Sat, 21 Dec 2024 18:19:57 -0600
> >> 
> >> The usual Dired icon is missing and instead shows up as a couple
> >> of tiny triangles in the normal state and as a very generic file
> >> icon on hover. Happens on emacs-30 and master and X11 and PGTK
> >> builds. Lucid and Motif builds are unaffected.
> >
> > Where do the tool-bar icons come from in that build?  They are not
> > from the Emacs's etc/images/ directory, AFAICT.
> 
> They are the stock GTK icons. On this system they are located in
> /usr/share/icons/. The option x-gtk-stock-map is responsible for
> the mapping between Emacs' etc/images/* and the system's
> icons. The attached patch fixes it here.

Can you explain the rationale for the patch and how it solves the
problem?

> > Can you post the Dired icon file from where your build takes them?
> 
> Unfortunately I can't find those particular icons among the ~7000
> icons in the /usr/share/icons/ directory but they're probably in
> there somewhere.

If you run Emacs under GDB with a breakpoint in lookup_image, you
should see all the tool-bar icons being loaded during startup.  You
can use the following GDB commands for the breakpoint, to see when the
icon you are interested in gets loaded:

  pp spec

This should show you the full absolute file name of the icon file
Emacs is loading.

The command "pp" is defined in src/.gdbinit, so if you don't start GDB
from that directory, you will need to say

  (gdb) source /path/to/emacs/src/.gdbinit

before running Emacs, to be able to use this useful command.

> > Also, is this problem new in the last pretest, or did previous
> > pretests behave the same?
> 
> I tried 30.0.90 and 29.4 and they too are using the incorrect
> icons. I suspect upgrading to Fedora 41 is what causes the
> issue.

Yes, that's usually the first suspect in such cases.

Thanks.