libGL error: failed to open swrast

[tP1rx]

Windows Version

Microsoft Windows [Version 10.0.22621.2428]

WSL Version

1.2.5.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.90.1

Distro Version

Ubuntu 22.04

Other Software

Anaconda

Repro Steps

start gmsh

Expected Behavior

open gmsh

Actual Behavior

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
XRequest.148: BadMatch (invalid parameter attributes) 0x0
Segmentation fault

Diagnostic Logs

No response

[tP1rx]

The isue is that the swrest cant be found although i have ensured that the library directory is specified in the ld conf. For some reason the linker still looks for swrast in usr/lib/dri although the file is in /usr/lib/x86_64-linux-gnu/.

The worst part is that i cant change the behaviour. Ive made sure that the directory of swrst is specified in the dynamic linker folder.

[tP1rx]

The problem orignates from error involving libGLU.so.1, while running a Python script that imports gmsh and dolfinx in a WSL Ubuntu environment. I solved initial problem by manual instalation of:

libglu1 \
libxcursor-dev \
libxft2 \
libxinerama1 \
libfltk1.3-dev \ 
libfreetype6-dev  \
libgl1-mesa-dev \
libocct-foundation-dev \
libocct-data-exchange-dev 

according to original post: https://fenicsproject.discourse.group/t/oserror-libglu-so-1/6021 although that error on its own is bizzare and should not have been a problem in the first place.
After resolving the libGLU.so.1 starting gmsh now results in the swrast error

[zcobol]

@deadP1rx /usr/lib/x86_64-linux-gnu path is added automatically by the glibc package. Check /etc/ld.so.conf.d/x86_64-linux-gnu.conf for details. And glibc is part of your system installation. Unless you messed with your linker's search paths there's no need to add this directory manually. Try running glxinfo -B and see if the command works, to give you info about your dri setup. Also, run ldconfig -v /usr/bin/gmsh to see what's missing preventing your app to start.

On Ubuntu 22.04 with radeon driver gmsh-4.8.4 starts okay:

[tP1rx]

hey, thx for the answer.
The x86_64-linux-gnu.conf file contains

# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

Ive created additional local file that specifies /usr/lib/x86_64-linux-gnu/dri but u r right that it might not be necessary, but I am quite desperate at the moment. I ve previously checked with ldconfig -p | grep swrast if the library appears in the cache but it returns nothing.

Basic GLX info looks fine, it specifies device, opengl version etc..

The gmsh works fine in the python environment. Apparently the problem is just with the GUI.

I tried also running pyvista for mesh visualisation with ipywidgets with trame but that explodes kernel every time i call the plot, func, even for simple examples. So i guess that the problem affects all graphics based processes (assuming that those errors are connected)

All that is quite unique behaviour, and i have not seen anything like that before

[OneBlue]

Converted to a discussion since the issue isn't related to WSL

[ChazMerritt]

Encountered this issue when trying to use networkx on a conda environment on WSL. My swrast_dri.so is there under "/usr/lib/x86_64-linux-gnu/dri" and even though the mesa-loader says that is a search path, it doesn't find the drivers.

[S-Yuan137]

I encountered a very similar error when doing something with Python plots using Matplotlib or Pyvista within my WSL2. Especially for pyvista, it stops the jupyter kernel. Thus, the reason may be the same even though I don't make sure.
It might be that the libstdc++.so within the conda virtual environment differs from the system one.
There are two methods:

1. make a soft link to system one, such as ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30 ~/.conda/envs/py311/lib/libstdc++.so.6
   OR
2. delete the libstdc++.so.6 in the conda env. (Make sure you have export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/" in your .bashrc or .zshrc when using this method.)

Note you need to modify the path and libstdc++.so.* version according to your machine. And backup your .so file when you try the above method so that you can recover/cancel these operations in case they do not work.