libGL error on fedora 36

[koppau]

Describe the bug trex and tgrabs fail to start, showing the following message:

libGL error: MESA-LOADER: failed to open radeonsi: /home/paul/.conda/envs/trex/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/dri/radeonsi_dri.so) (search paths /usr/lib64/dri, suffix _dri)

Probably building against a newer version of libstdc++ solves the issue (see Additional context below)

To Reproduce Steps to reproduce the behavior:

1. Start program with command-line 'trex'
2. see error

If possible, please also include the full terminal output as a file attachment.

Expected behavior (if it is not a simple crash) Start the program.

Computer (please complete the following information):

• Operating system: fedora 36 Workstation Edition
• Build hash [search for build in the settings box]
• Terminal used gnome-terminal with bash

Additional context This only happens with the prebuilt package from conda (using the install instructions on trex.run). I built it myself on the target machine (also using the instructions in the documentation), which works fine.

Further investigation using

strings ~/.conda/envs/trex/lib/libstdc++.so.6 | grep GLIBCXX

showed GLIBCXX_3.4.29 as the latest version, which indicates that building against a newer version of glibc++ might resolve the issue. As expected, the system libstdc++ also contains GLIBCXX_3.4.20, which explains why a local build works as expected.

[mooch443]

Hey there,

libGL error: MESA-LOADER: failed to open radeonsi: /home/paul/.conda/envs/trex/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/dri/radeonsi_dri.so) (search paths /usr/lib64/dri, suffix _dri)

So I presume starting with -nowindow would theoretically work? Or are there more such issues/is it just the Radeon driver?

Further investigation using

strings ~/.conda/envs/trex/lib/libstdc++.so.6 | grep GLIBCXX

showed GLIBCXX_3.4.29 as the latest version, which indicates that building against a newer version of glibc++ might resolve the issue. As expected, the system libstdc++ also contains GLIBCXX_3.4.20, which explains why a local build works as expected.

I assume you mean that your system libstdc++ contains glibc 3.4.30? That would make sense, yes. It seems that Radeon do not, for some reason, statically link against their libstdc++ version. And then, within a conda environment that contains a libstdc++.so, only that libstdc++ is found and does not contain the correct versions. Unfortunate. Maybe there is a way to prioritize your system's .so?

I don't have a test system with Fedora and an AMD at hand, but you could test something like this: (paths might have to be adjusted to reflect your system's)

(trex119) $ LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu LD_DEBUG=libs trex 2>&1 | grep "libstdc++"

The issue with fixing this is that I can only (easily) build against the libstdc++ versions that are available on anaconda. The only alternative would be building against conda-forge (and thus adding a dependency on that channel which I wish to avoid), or, in your case, manually installing the libstdcxx-ng package from conda-forge into your trex environment. This would overwrite the one at ~/.conda/envs/trex/lib/.

(trex119) $ conda install -c conda-forge libstdcxx-ng

This worked for me at least without causing too many hickups. Let me know if this works as a temporary remedy for you as well. Thanks!

[koppau]

Thanks for the reply! Running with -nowindow worked without any errors (didn't know that such an option exists, RTFM I guess). Same for the libstdcxx-ng package from conda-forge.

There's probably not many people running this on a Radeon GPU, but you may want to consider adding a hint to the FAQ page in case something similar happens again.

[mooch443]

Added a small note here. Thanks for reporting!