google earth pro ne demarre pas opensuse

On compare souvent l'installation d'un binaire sur un système ouvert et sur un système fermé. Sur Linux, le parcours est exigeant mais permet de maîtriser les risques. Sur Windows, l'installation est simple, mais la maîtrise des risques est limitée. Installer Google Earth Pro sur openSUSE Tumbleweed devient le début d'une enquête méthodique, du premier crash jusqu'à la solution stable.

🔍 Rappel des faits

Google Earth Pro reste un outil apprécié : imagerie satellite, mesures, vues 3D, données historiques. Sur Linux, Google le distribue toujours sous la forme d'un paquet .rpm (ou .deb) autonome. Le hic : ce paquet est figé sur des bibliothèques d'une autre époque — un Qt 5.5Bibliothèque graphique sortie en 2015. Google Earth la fournit en interne, sans suivre les versions modernes du système (Qt 5.15 ou Qt 6). de 2015 et un OpenSSL 1.0Bibliothèque cryptographique en fin de vie (EOL). Les distributions actuelles sont passées à OpenSSL 3.x, dont l'interface binaire est incompatible. en fin de vie.

Sur une distribution stableCycle de publication lent, privilégiant la fiabilité et les tests approfondis plutôt que les versions les plus récentes. et conservatrice, ça passe encore. Mais sur une rolling releaseModèle de mise à jour continue où les logiciels sont livrés dès qu'ils sont prêts, sans versions majeures figées. à jour comme openSUSE Tumbleweed, durcie avec SELinux enforcingMode de SELinux où les règles de sécurité sont activement appliquées et bloquent toute action non autorisée. et une session WaylandProtocole d'affichage moderne qui remplace X11. Les applications anciennes prévues pour X11 y fonctionnent via une couche de compatibilité, XWayland., le décalage devient frontal : le paquet s'installe, mais l'application ne s'ouvre pas.

🧭 Le point de départ : un clic, puis rien

Premier réflexe après l'installation : cliquer sur l'icône. Rien ne s'ouvre. Pas de fenêtre, pas de message. Quand une application graphique reste muette, la règle d'or est de la relancer depuis un terminalInterface texte permettant d'exécuter des commandes et de visualiser les messages d'erreur bruts des applications. : c'est là que les vrais messages d'erreur apparaissent.

/opt/google/earth/pro/googleearth-bin
Copier
Copié

Et là, le premier indice tombe. Le voyage commence.

🧱 Premier obstacle — la pile exécutableZone mémoire de la pile marquée comme exécutable, pratique risquée que les systèmes durcis interdisent. refusée

libcrypto.so.1.0.0: cannot enable executable stack
as shared object requires: Permission denied
Copier
Copié

Traduction : la vieille bibliothèqueFichier contenant du code réutilisable (.so sous Linux) que les programmes chargent pour fonctionner. libcrypto embarquée réclame une pile exécutable, et le système refuse. Plutôt que de deviner, on demande à SELinux ce qu'il a bloqué :

sudo ausearch -m avc -ts recent | grep execstack
# avc: denied { execstack } for comm="googleearth-bin" ... permissive=0
Copier
Copié

Le verdict est sans appel : un AVC« Access Vector Cache » — la ligne de journal SELinux qui indique précisément quelle action a été refusée, par quel processus et sur quelle ressource. denied { execstack } en mode permissive=0 (donc réellement bloqué). Avant de corriger, une question : est-ce la seule bibliothèque fautive ? On inspecte tous les binaires du dossier pour repérer le drapeau de pile exécutable (RWE) avec la commande for f in; do readelf ; grep -qBoucle shell combinant readelf (lecture des en-têtes ELF) et grep (recherche silencieuse) pour inspecter plusieurs fichiers. :

for f in /opt/google/earth/pro/lib*.so*; do
  readelf -l "$f" 2>/dev/null | grep -q 'GNU_STACK.*RWE' && echo "$f"
done
# -> /opt/google/earth/pro/libcrypto.so.1.0.0
Copier
Copié

Une seule. Le problème est donc circonscrit : inutile de prendre un marteau pour écraser une mouche.

La bonne porte (et la mauvaise)

setsebool -P selinuxuser_execstack on

#!/usr/bin/env python3
import struct
f = "/opt/google/earth/pro/libcrypto.so.1.0.0"
d = bytearray(open(f, "rb").read())
phoff     = struct.unpack_from("<Q", d, 0x20)[0]
phentsize = struct.unpack_from("<H", d, 0x36)[0]
phnum     = struct.unpack_from("<H", d, 0x38)[0]
for i in range(phnum):
    o = phoff + i * phentsize
    if struct.unpack_from("<I", d, o)[0] == 0x6474E551:   # PT_GNU_STACK
        fl = struct.unpack_from("<I", d, o + 4)[0]
        struct.pack_into("<I", d, o + 4, fl & ~0x1)       # retire PF_X
        open(f, "wb").write(d); print("PF_X retire"); break
Copier
Copié
            

sudo cp -a /opt/google/earth/pro/libcrypto.so.1.0.0 \
           /opt/google/earth/pro/libcrypto.so.1.0.0.bak
Copier
Copié
            

readelf -l /opt/google/earth/pro/libcrypto.so.1.0.0 | grep -A1 GNU_STACK
Copier
Copié
            

🧨 Deuxième mur — le crash « signal 6 »

Google Earth has caught signal 6.
Copier
Copié

Un signal 6 (SIGABRT)Signal d'« abandon » : le programme s'auto-termine après avoir détecté une condition fatale, souvent via une assertion interne. survient quasi instantanément. Le journal de crash, dans ~/.googleearth/crashlogs/, pointe vers l'initialisation de QtFramework graphique utilisé pour créer des interfaces utilisateur, dont Google Earth embarque une version spécifique. :

QGuiApplicationPrivate::createEventDispatcher
  -> QMessageLogger::fatal -> abort
Copier
Copié

Le pluginModule externe chargeable à la volée qui étend les fonctionnalités d'un logiciel (ex: plugin xcb de Qt). xcb de ce vieux Qt s'effondre à l'initialisation. Détail crucial : toutes les bibliothèques se chargent correctement — ce n'est donc pas une dépendance manquante, mais l'initialisation graphique elle-même qui échoue, probablement du côté de l'intégration GLXLa couche qui relie OpenGL au serveur X. Le vieux plugin xcb tente d'y accéder en mode matériel et abandonne sur la pile graphique moderne. matérielle.

Par élimination : tester, écarter, recommencer

C'est ici que le dépannage devient un vrai parcours. On émet une hypothèse — « c'est l'OpenGL matérielRendu 3D accéléré par le GPU (carte graphique), rapide mais parfois incompatible avec les vieilles librairies. qui coince » — et on la teste par paliers, en notant ce qui échoue.

Voici les trois commandes (ou variations) que nous avons testées pour isoler le coupable, avec leurs résultats réels (testés sur openSUSE Tumbleweed, session Wayland) :

QT_QPA_PLATFORM=xcb QT_XCB_GL_INTEGRATION=none /opt/google/earth/pro/googleearth

QT_QUICK_BACKEND=software QT_XCB_GL_INTEGRATION=none /opt/google/earth/pro/googleearth

QT_QPA_PLATFORM=xcb QT_XCB_GL_INTEGRATION=none LIBGL_ALWAYS_SOFTWARE=1 /opt/google/earth/pro/googleearth

La combinaison gagnante est donc la option A : elle isole exactement le point de rupture — l'intégration OpenGL du plugin xcb — et le contourne sans toucher aux performances GPU.

QT_QPA_PLATFORM=xcb QT_XCB_GL_INTEGRATION=none /opt/google/earth/pro/googleearth
Copier
Copié

🧩 La solution pérenne

Lancer cette variable à la main à chaque fois n'est pas tenable. On confine donc le correctif à Google Earth, via des fichiers utilisateur (qui survivent aux mises à jour du paquet).

cat > ~/.local/bin/google-earth-pro <<'EOF'
#!/bin/sh
# Le crash venait de l'intégration GL du plugin xcb (Qt 5.5), PAS du GPU.
# Fix retenu (option A, testé 2026-06-20) : forcer la plateforme xcb + désactiver
# l'intégration GL du plugin. L'accélération GPU est CONSERVÉE (3D fluide).
# Repli si A échoue sur un pilote : décommenter la ligne ci-dessous pour
# forcer le rendu logiciel (LIBGL_ALWAYS_SOFTWARE=1).
export QT_QPA_PLATFORM=xcb
export QT_XCB_GL_INTEGRATION=none
# export LIBGL_ALWAYS_SOFTWARE=1   # décommenter pour le repli logiciel
exec /opt/google/earth/pro/googleearth "$@"
EOF
chmod +x ~/.local/bin/google-earth-pro
Copier
Copié
            

cat > ~/.local/share/applications/google-earth-pro.desktop <<'EOF'
[Desktop Entry]
Version=1.0
Name=Google Earth Pro
Comment=Explore, search and discover the planet
Exec=/home/UTILISATEUR/.local/bin/google-earth-pro %f
Terminal=false
Icon=google-earth-pro
Type=Application
Categories=Application;Network;
EOF
update-desktop-database ~/.local/share/applications
Copier
Copié
            

🗺️ Le parcours en un coup d'œil

🏁 Conclusion : méthode de dépannage et état des lieux du binaire

Au-delà de Google Earth, ce parcours illustre une méthode de résolution applicable à n'importe quel bug :

La leçon est plus large que Google Earth : un binaire propriétaire figé sur un instantané de système vieillit mal face à un OS qui, lui, avance. Le contournement présenté ici (option A) est propre, réversible, confiné et conserve l'accélération matérielle — exactement ce qu'on attend d'un correctif sur un poste qu'on tient à garder sûr et performant.

🔗 Sources et références

📚 Lectures Recommandées SafeITExperts

Si ce dépannage vous a plu, ces articles prolongent la réflexion sur Linux, openSUSE et la résolution de problèmes :