Qt: Difference between revisions
imported>Samueldr Inits with with link to incompatible Qt library issue |
imported>Symphorien explain how to launch qt apps from a systemd user service |
||
Line 6: | Line 6: | ||
This is a known issue, see {{issue|30551}} for the current status. | This is a known issue, see {{issue|30551}} for the current status. | ||
=== This application failed to start because it could not find or load the Qt platform plugin ??? in "" === | |||
==== qt4 ==== | |||
Qt4 depends on the environment variable <code>QT_PLUGIN_PATH</code> to find plugins. It is normally already | |||
present in the environment on NixOS at least, but for example systemd user units are launched in a pretty empty environment. A solution is to use the command {{Commands|systemctl --user import-environment QT_PLUGIN_PATH}} from a sane environment. For example add it to the <code>services.xserver.displayManager.sessionCommands</code> option. | |||
==== qt5 ==== | |||
Qt5 seems (?) to look for plugins in the <code>PATH</code>. This will fail from a systemd user unit for example, because their path is nearly empty by default. As an example, here is a workaround to have </code>usbguard-applet</code> launched from a systemd user unit: | |||
{{File|/etc/nixos/configuration.nix|nix|<nowiki> | |||
systemd.user.services.usbguard-applet = { | |||
description = "USBGuard applet"; | |||
partOf = [ "graphical-session.target" ]; | |||
wantedBy = [ "graphical-session.target" ]; | |||
path = [ "/run/current-system/sw/" ]; ### Fix empty PATH to find qt plugins | |||
serviceConfig = { | |||
ExecStart = "${pkgs.usbguard}/bin/usbguard-applet-qt"; | |||
}; | |||
}; | |||
</nowiki>}} | |||
==== Debugging methods ==== | |||
As a general rule, exporting <code>QT_DEBUG_PLUGINS=1</code> make qt print where it looks for plugins. | |||
If a plugin exists in a directory but is ignored with a message like <code>QLibraryPrivate::loadPlugin failed on "/nix/store/...-teamspeak-client-3.1.6/lib/teamspeak/platforms/libqxcb.so" : "Cannot load library /nix/store/...-client-3.1.6/lib/teamspeak/platforms/libqxcb.so: "</code> it can be that the library cannot be <code>dlopen()</code>ed because of dependencies/rpath issues and needs <code>patchelf</code>ing. Exporting <code>LD_DEBUG=libs</code> may prove helpful in this scenario. |
Revision as of 14:03, 31 May 2018
Troubleshooting
Cannot mix incompatible Qt library (version 0x_____) with this library (version 0x_____)
This is a known issue, see #30551 for the current status.
This application failed to start because it could not find or load the Qt platform plugin ??? in ""
qt4
Qt4 depends on the environment variable QT_PLUGIN_PATH
to find plugins. It is normally already
present in the environment on NixOS at least, but for example systemd user units are launched in a pretty empty environment. A solution is to use the command
systemctl --user import-environment QT_PLUGIN_PATH
from a sane environment. For example add it to the services.xserver.displayManager.sessionCommands
option.
qt5
Qt5 seems (?) to look for plugins in the PATH
. This will fail from a systemd user unit for example, because their path is nearly empty by default. As an example, here is a workaround to have usbguard-applet launched from a systemd user unit:
/etc/nixos/configuration.nix
systemd.user.services.usbguard-applet = {
description = "USBGuard applet";
partOf = [ "graphical-session.target" ];
wantedBy = [ "graphical-session.target" ];
path = [ "/run/current-system/sw/" ]; ### Fix empty PATH to find qt plugins
serviceConfig = {
ExecStart = "${pkgs.usbguard}/bin/usbguard-applet-qt";
};
};
Debugging methods
As a general rule, exporting QT_DEBUG_PLUGINS=1
make qt print where it looks for plugins.
If a plugin exists in a directory but is ignored with a message like QLibraryPrivate::loadPlugin failed on "/nix/store/...-teamspeak-client-3.1.6/lib/teamspeak/platforms/libqxcb.so" : "Cannot load library /nix/store/...-client-3.1.6/lib/teamspeak/platforms/libqxcb.so: "
it can be that the library cannot be dlopen()
ed because of dependencies/rpath issues and needs patchelf
ing. Exporting LD_DEBUG=libs
may prove helpful in this scenario.