gdk-pixbuf: Use a different GDK_PIXBUF_MODULE_FILE environment variable on 32-bit and 64-bit systems.

[ambrop72]

Pull request #42562 caused a regression that running a 32-bit program that uses
gdk-pixbuf would result in a crash because it would try to load a 64-bit
library and fail. This change fixes this issue by patching gdk-pixbuf and many
places where this variable is defined to use different variable names on
32-bit and 64-bit systems.

Motivation for this change

Fix regression running 32-bit programs.

This only intends to fix the 32-bit program issue. The situation is still a mess. The way I understand the situation is:

• Desktops want to set GDK_PIXBUF_MODULE_FILE such that all GTK apps will be able to load SVG icons. I presume this is because the desktop comes with SVG icons and the apps should be able to use the desktop-provided icons to integrate visually.
• Some apps need to specifically support SVG icons, probably because they ship with them. Those set GDK_PIXBUF_MODULE_FILE in the wrapper (the value comes from the gdk-pixbuf setup hook). In these cases the wrapper sets the variable to point to the cache file in librsvg.
• Some apps set GDK_PIXBUF_MODULE_FILE in the wrapper without depending on librsvg, which results in the wraper setting the variable to the cache file from gdk-pixbuf. This wrapping might be to ensure the app works even if GDK_PIXBUF_MODULE_FILE is set incorrectly (e.g. when NixOS is updated, if running outside NixOS) (if it is not set gdk-pixbuf will use its default cache file). Note that these apps will never support SVG icons even if the desktop sets the variable, because the wrapper overrides it! That's why I added a librsvg dependency to some apps, but I didn't check this for the many apps that get wrapped indirectly via wrapGAppsHook.

My suggestion going forward would be to try to ensure that (almost?) all GTK apps are wrapped to set GDK_PIXBUF_MODULE_FILE to the one from librsvg (yes, it results in a larger closure in some cases), and then remove the code in desktops to set the environment variable together with the gdk-pixbuf NixOS module.

Things done

I have testes this on 19.03 branch and it seems to work as intended. I have checked that the correct variable is set by the gdk_pixbuf NixOS module and that the apps which set it in the wrapper set the correct variable. I have observed no breakage on my desktop system (KDE-based). I have tried running a 32-bit application (pavucontrol) and it does start and run (though there are errors loading 64-bit GVFS plugins).

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[ambrop72]

Note that in the referenced pull request #42562 there was a suggestion from @jtojnar that this could be solved by making sure librsvg included in wrappers and removing the variable setting from desktops. As already stated I agree with this approach, however the 32-bit program issue would still exist for any child processes of a wrapped program (e.g. if a terminal is a GTK app that is wrapped in this way), hence this pull request.

[jtojnar]

however the 32-bit program issue would still exist for any child processes of a wrapped program (e.g. if a terminal is a GTK app that is wrapped in this way), hence this pull request.

Would not the child process be wrapped too with platform-correct modules?

[ambrop72]

however the 32-bit program issue would still exist for any child processes of a wrapped program (e.g. if a terminal is a GTK app that is wrapped in this way), hence this pull request.

Would not the child process be wrapped too with platform-correct modules?

Certainly not all apps that use gdk-pixbuf are wrapped to set the variable. Until someone goes chasing all apps that are not and wrapping them, the issue still exists.

Anyway I am currently working on an idea to solve the problem of children inheriting variables set by wrappers, and it seems like there is a way with only minor modifications of programs. So I think we should just apply this as an immediate fix until we have a proper approach to such problems.

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[Ericson2314]

IMO we should do something like cc-wrapper's "suffix salt" to support multiple platforms more thoroughly than just 64 vs 32 CC @matthewbauer

[stale]

I marked this as stale due to inactivity. → More info