I run SNAP on a couple headless servers with VNC for GUI requirements such as World View. On both systems, the first invocation of SNAP 9.0 produced a blank “World View” and an error message:
[snap9@server ~]$ snap
libEGL warning: MESA-LOADER: failed to open swrast: /home/gwhite/.snap/auxdata/gdal/gdal-3-2-1/lib/jni/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/swrast_dri.so) (search paths /usr/lib64/dri, suffix _dri)
The “messages.log” has more details, but this was enough to pinpoint the problem: the MESA library was build against the system libstdc++ which is newer than the version provided in SNAP. I didn’t try deleting SNAP’s old version of libstdc++ because it might get replaced. Keeping the old and new versions together makes it easier to see any future changes.
A workaround is to replace the above libstdc++.so.6 with the “system” version: First, rename the existing library to reflect the version (here, 6.0.25), then copy the current system library (I tried a symbolic link but got “access denied” – maybe an SELINUX feature) and update the symbolic link.
It sounds like a Red Hat-based distro like Fedora, CentOS or RHEL, or a derivative of those.
You’ve diagnosed this nicely. The problem is that the GDAL plugin has to load some native libraries like libjpeg and libtiff, compiled on some specific Linux distribution. So the bundle includes these, but also libstdc++.so, the idea being that it should work even if you’re running on a different distribution or version of it.
Unfortunately, you can’t really load two versions of a library inside a process, so SNAP ends up with a very old libstdc++.so, which doesn’t work for the system Mesa. This is hard to solve without trying to switch to a static build of GDAL, but I see two other problems with the current setup, and fixing either of the two might be a good workaround here:
SNAP/GPT initializes GDAL right from the start, even if it’s not used, causing (in addition to this problem) some annoying warnings and slowing down the startup.
GPT tries to initialize OpenGL even though it’s not going to work very well – or be necessary, since AIUI it’s only used for the Globe viewer.
Just to report a similar problem (probably, the same) when running SNAP 9.0 in WSL2 (Windows Subsystem Linux):
./opt/snap/bin/snap
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
Also, shows the following error at the start up:
Unable to initialize WWWorldMapToolView: Profiles [GL4bv, GL3bc, GL2, GLES1] not available on device null
You don’t mention the linux distro and version, or the X11 graphics system you are using.
appears to be a different problem that needs to be solved with changes to your linux and/or X11 configuration. Posting more details in a new topic such as "Unable to initialize WWWorldMapToolView in WSL2 using " may get help from a SNAP user with a similar configuration. Otherwise you need to work with WSL2, and forums.
The distribution inside WSL is Ubuntu 20.04.4 LTS. On the other hand, I have solved the issue following the approach proposed in the first post. I have changed the libstdc++ in auxdata/gdal/gdal-3-2-1/lib by the one used by the Linux distribution. Afterwards, all the problems solved (at least, it looks like that).