google earth pro wont start opensuse

We often compare installing a binary on an open system versus a closed system. On Linux, the journey is more demanding but allows better control over risks. On Windows, installation is simpler, but risk control is limited. Installing Google Earth Pro on openSUSE Tumbleweed becomes the start of a methodical investigation — from the first crash to a stable solution.

🔍 Background

Google Earth Pro remains a popular tool: satellite imagery, measurements, 3D views, historical data. On Linux, Google still distributes it as a self-contained .rpm (or .deb) package. The catch: this package is frozen on libraries from another era — a Qt 5.5Graphics library released in 2015. Google Earth ships it internally, ignoring modern system versions (Qt 5.15 or Qt 6). from 2015 and a long‑end‑of‑life OpenSSL 1.0Cryptographic library past its end of life. Current distributions have moved to OpenSSL 3.x, whose binary interface is incompatible..

On a conservative stable distributionSlow release cycle, prioritising reliability and extensive testing over the newest versions., it works. But on an up‑to‑date rolling releaseContinuous update model where software ships as soon as it's ready, without fixed major releases. like openSUSE Tumbleweed, hardened with SELinux enforcingMode where SELinux actively enforces security policies and blocks unauthorised actions. and a WaylandModern display protocol replacing X11. Older X11‑only applications run via a compatibility layer, XWayland. session, the mismatch becomes glaring: the package installs, but the application refuses to open.

🧭 Starting point: a click, then nothing

First reflex after installation: click the icon. Nothing opens. No window, no message. When a graphical application stays silent, the golden rule is to launch it from a terminalText interface allowing you to run commands and see raw error messages from applications. — that's where the real error messages appear.

/opt/google/earth/pro/googleearth-bin
Copy
Copied

And there, the first clue drops. The journey begins.

🧱 First roadblock — executable stackMemory stack marked as executable, a risky practice that hardened systems reject by default. denied

libcrypto.so.1.0.0: cannot enable executable stack
as shared object requires: Permission denied
Copy
Copied

Translation: the bundled old libraryReusable code file (.so on Linux) that programs load to work. libcrypto demands an executable stack, and the system refuses. Rather than guess, we ask SELinux what it blocked:

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

The verdict is clear: an AVC"Access Vector Cache" — the SELinux log line that precisely indicates which action was denied, by which process and on which resource. denied { execstack } in permissive=0 (so actually blocked). Before fixing, one question: is this the only offending library? We scan all binaries in the folder for the executable stack flag (RWE) using the command for f in; do readelf ; grep -qShell loop combining readelf (ELF header reader) and grep (quiet search) to inspect multiple files.:

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
Copy
Copied

Only one. The problem is contained — no need for a sledgehammer to crack a nut.

The right door (and the wrong one)

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)       # remove PF_X
        open(f, "wb").write(d); print("PF_X removed"); break
Copy
Copied
            

sudo cp -a /opt/google/earth/pro/libcrypto.so.1.0.0 \
           /opt/google/earth/pro/libcrypto.so.1.0.0.bak
Copy
Copied
            

readelf -l /opt/google/earth/pro/libcrypto.so.1.0.0 | grep -A1 GNU_STACK
Copy
Copied
            

🧨 Second wall — the "signal 6" crash

Google Earth has caught signal 6.
Copy
Copied

A signal 6 (SIGABRT)"Abort" signal — the program self‑terminates after detecting a fatal condition, often via an internal assertion. occurs almost instantly. The crash log in ~/.googleearth/crashlogs/ points to QtGraphical framework used to build user interfaces, of which Google Earth embeds a specific version. initialisation:

QGuiApplicationPrivate::createEventDispatcher
  -> QMessageLogger::fatal -> abort
Copy
Copied

The pluginLoadable module that extends a software's functionality (e.g. the xcb plugin for Qt). xcb of this old Qt crashes during initialisation. Crucial detail: all libraries load correctly — so it's not a missing dependency, but the graphical initialisation itself that fails, probably on the GLXThe layer connecting OpenGL to the X server. The old xcb plugin tries to access it in hardware mode and fails on the modern graphics stack. hardware integration.

By elimination: test, discard, try again

This is where the troubleshooting becomes a real journey. We hypothesise — "it's hardware OpenGL3D rendering accelerated by the GPU (graphics card), fast but sometimes incompatible with older libraries. that's failing" — and we test in steps, noting what fails.

Here are the three commands (or variations) we tested to isolate the culprit, with their real results (tested on openSUSE Tumbleweed, Wayland session):

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

The winning combination is therefore option A: it isolates the exact breaking point — the OpenGL integration of the xcb plugin — and bypasses it without touching GPU performance.

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

🧩 The permanent solution

Typing this variable each time isn't sustainable. So we confine the fix to Google Earth using user‑level files (which survive package updates).

cat > ~/.local/bin/google-earth-pro <<'EOF'
#!/bin/sh
# The crash came from the GL integration of the xcb plugin (Qt 5.5), NOT from the GPU.
# Fix retained (option A, tested 2026-06-20): force xcb platform + disable
# the plugin's GL integration. GPU acceleration is CONSERVED (smooth 3D).
# Fallback if A fails on a specific driver: uncomment the line below to
# force software rendering (LIBGL_ALWAYS_SOFTWARE=1).
export QT_QPA_PLATFORM=xcb
export QT_XCB_GL_INTEGRATION=none
# export LIBGL_ALWAYS_SOFTWARE=1   # uncomment for software fallback
exec /opt/google/earth/pro/googleearth "$@"
EOF
chmod +x ~/.local/bin/google-earth-pro
Copy
Copied
            

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/USER/.local/bin/google-earth-pro %f
Terminal=false
Icon=google-earth-pro
Type=Application
Categories=Application;Network;
EOF
update-desktop-database ~/.local/share/applications
Copy
Copied
            

🗺️ The journey at a glance

🏁 Conclusion: troubleshooting method and the state of the binary

Beyond Google Earth, this journey illustrates a methodology that applies to any bug:

The lesson goes beyond Google Earth: a proprietary binary frozen to a point‑in‑time system ages poorly against an OS that keeps moving forward. The workaround presented here (option A) is clean, reversible, confined and preserves hardware acceleration — exactly what you want from a fix on a machine you intend to keep both safe and performant.

🔗 Sources and references

📚 Recommended Reading SafeITExperts

If you enjoyed this troubleshooting story, these articles extend the reflection on Linux, openSUSE and problem‑solving: