# Trouble Running ParaView 5.13.3 on HPC Cluster: Missing libGL.so.1 and libglapi.so.0
**URL:** https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749
**Category:** ParaView Support
**Tags:** opengl, python
**Created:** [May 30, 2025, 8:48pm UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749 "2025-05-30T20:48:18Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Hemiao\_Zhang](https://discourse.paraview.org/u/Hemiao_Zhang)
#### Post date: [May 30, 2025, 8:48pm UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/1 "2025-05-30T20:48:18Z")
Hi all,
I’m trying to install and run ParaView 5.13.3 on a Linux-based HPC system (Stanford’s Sherlock cluster), but I’m running into some shared library issues. I’ve tested both:
- The standard MPI Linux build: ParaView-5.13.3-MPI-Linux-Python3.10-x86\_64
- The OSMesa (headless) build: ParaView-5.13.3-osmesa-MPI-Linux-Python3.10-x86\_64
When I run pvpython from either installation, I get errors like the following:
```
error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
```
Or, for the OSMesa version:
```
error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory
```
Running ldd on pvpython-real confirms that these shared objects are missing. I tried loading system modules like libglvnd, xorg, and mesa, but no luck so far.
Is there a way to run the OSMesa version of ParaView fully headless on a CPU-only HPC cluster without needing libGL.so.1?
I’m mainly interested in using pvpython for batch visualization and post-processing in an automated pipeline (no GUI).
Thanks in advance for your help!
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [June 2, 2025, 12:13pm UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/2 "2025-06-02T12:13:35Z")
`libglapi.so.0` is provided in the binary package of the headless version:
`ParaView-5.13.3-osmesa-MPI-Linux-Python3.10-x86_64/lib/mesa/libglapi.so`
But for some reason the rpath was not set correctly. You can work around this issue with:
```auto
LD_PRELOAD=./lib/mesa/libglapi.so ./bin/pvserver-real
```
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 13, 2025, 10:07am UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/3 "2025-06-13T10:07:31Z")
> [@mwestphal](#):
>
> `LD_PRELOAD=./lib/mesa/libglapi.so ./bin/pvserver-real`
`./bin/pvserver --mesa` is the “intended” mechanism.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [June 13, 2025, 10:12am UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/4 "2025-06-13T10:12:34Z")
I’m a bit confused now, if we always need it with osmesa binary, why do we rely on the one from the system by default ?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [June 13, 2025, 10:32am UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/5 "2025-06-13T10:32:57Z")
Hmm. We shouldn’t need OSMesa until the class(es) that use it are instantiated. Could be an unforeseen change from the backend change. @jaswantp?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [June 13, 2025, 11:18am UTC](https://discourse.paraview.org/t/trouble-running-paraview-5-13-3-on-hpc-cluster-missing-libgl-so-1-and-libglapi-so-0/16749/6 "2025-06-13T11:18:55Z")
This doesnt concern the backend change, because this concerns only the release released before the backend change.