Google Chrome не Запустится - Не могущий определить местоположение механизма темы в module_path: “adwaita”

Первая часть моего ответа:

Для GTK theme error: Unable to locate theme engine in module_path: "pixmap"

sudo apt-get install  gtk2-engines-pixbuf:i386

Проблема, кажется, только происходит с i386 версией Google Chrome в 64-разрядной системе Ubuntu. Подсказка, что это было 32-разрядное по сравнению с 64-разрядной проблемой, состояла в том, что, устанавливая :i386 версия определенных пакетов, совершенных, некоторые ошибки уходят. Я смог получить Chrome, работающий снова путем установки 64-разрядной версии:

$ sudo aptitude install google-chrome-stable

The following packages have unmet dependencies:
 libappindicator1 : Conflicts: libappindicator1:i386 but 12.10.1+15.04.20141110-0ubuntu1 is installed.
 libappindicator1:i386 : Conflicts: libappindicator1 but 12.10.1+15.04.20141110-0ubuntu1 is to be installed.
 google-chrome-stable : Conflicts: google-chrome-stable:i386 but 42.0.2311.152-1 is installed.
 google-chrome-stable:i386 : Conflicts: google-chrome-stable but 42.0.2311.152-1 is to be installed.
 libindicator7 : Conflicts: libindicator7:i386 but 12.10.2+14.10.20140922-0ubuntu1 is installed.
 libindicator7:i386 : Conflicts: libindicator7 but 12.10.2+14.10.20140922-0ubuntu1 is to be installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     google-chrome-stable:i386   
2)     libappindicator1:i386       
3)     libindicator7:i386          

Accept this solution? [Y/n/q/?] 

я принял, что предлагаемое решение обновило несколько пакетов до 64-разрядной версии, и Chrome работает снова.

У меня была эта та же проблема, и mkasberg имел решение - чтобы удалить 32 бита и переустановить 64 бита. Я перешел к google.com/chrome и загрузил 64 бита .deb как нормальные. Я выполнил .deb, и стабильный Google Chrome был открыт в Центре программного обеспечения. Установленный это, который пошел прекрасный, но это складывается, google-chrome-stable:i386 был установлен вместо этого.

$ sudo apt-get remove google-chrome-stable:i386
$ sudo apt-get install google-chrome-stable

Наклон всегда обновляет приложение, это работало на меня

$ sudo apt install gnome-themes-standard:i386

Я использовал установку gtk с префиксом / usr / src / ClawsMail / install . Вышеупомянутое предупреждение печатается после печати (strace):

access("/home/carlo/.gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)

Предполагая, что это нормально, что в моем домашнем каталоге ничего не найдено, и поскольку моя установка в / usr / src / ClawsMail / install является ненормальной, я Я предполагаю, что обычно libadwaita.so будет найден <префикс> /lib/gtk-2.0 / ... , но я не устанавливал libadwaita с тем же префиксом.

ОДНАКО - после просмотра в / usr / src / ClawsMail / install он продолжает поиск в /usr/lib/gtk-2.0 / ... , так что не должно быть разница, если обычная установка находится в / usr .

В моей системе ДЕЙСТВИТЕЛЬНО установлен libadwaita.so , и вот здесь:

/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/libadwaita.so

Обратите внимание, что /usr/lib/gtk-2.0 даже не существует.

Оказывается, этот поиск происходит во время вызова

_gtk_find_module (name=0x5555557ee0e0 "adwaita", type=0x7ffff7b0c776 "engines") at gtkmodules.c:196

, и что искомые пути возвращаются

paths = _gtk_get_module_path (type);

, который получает три префикса из

gchar **paths = get_module_path();

. Оказывается, последний префикс ( / usr / lib / gtk-2.0 ) называется pre_multiarch_dir , то есть префиксом перед мультиархивом; который действительно больше не используется.

Моя проблема в том, что у меня нет установленных движков с тем же префиксом, что и в том месте, где я установил gtk-2.0. Однако поиск может быть расширен с помощью переменных среды:

Если задано GTK_EXE_PREFIX , то $ GTK_EXE_PREFIX / lib / gtk-2.0 будет использоваться вместо из префикс установки gtk-2.0 и pre_multiarch_dir (поэтому бесполезен в современных мультиархитектурных дистрибутивах).

Если GTK_PATH установлен, то он будет использоваться поверх всего остального. Я считаю, что последний может быть даже списком путей, разделенных точкой с запятой.

Таким образом, использование

export GTK_PATH="/usr/lib/x86_64-linux-gnu/gtk-2.0"

заставило меня снять предупреждение.