Re: gs unable to open shared library on TW
W dniu 10.12.2021 o 13:07, Jogchum Reitsma pisze:
Op 09-12-2021 om 12:31 schreef Adam Mizerski:
W dniu 09.12.2021 o 12:20, Jogchum Reitsma pisze:
Hi,
When I try to run gs, it says
gs: error while loading shared libraries: libpcre2-8.so.0: failed to map segment from shared object
libpcre2-8.so.0 is present on the system, as a link to libpcre2-8.so.0.10.4 in both /usr/lib and /usr/lib64
There is also a variant in /usr/local/lib64, this time linking to libpcre2-8.so.0.8.0
Any idea how I can get gs to life back again?
regards, Jogchum
Anything in /usr/local is something you had to install manually.
If by "install manually" you mean installed outside yast2, that is not entirely true: cuda, for example, is installed by yast in /usr/local. But maybe I misunderstand what you mean.
Well, you're right, that cuda from official nvidia rpm repository installs files into /usr/local. But it should not. According to "Filesystem Hierarchy Standard" chapter "4.9. /usr/local : Local hierarchy" (https://refspecs.linuxbase.org/FHS_3.0/fhs/ch04s09.html) "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated." So you understood correctly, but cuda breaks the rule.
There is a conflict between libpcre in /usr/local/lib64 and /usr/lib64. You should: 1) investigate how did you get those libraries in /usr/local It is from a pcre2 installation,NOT installed through yast or zypper. No idea why, it's from October 2019. 2) remove the conflicting libraries from /usr/local
I'll remove the who pcre2 thing, I suppose.
Thanks!
I'm glad I could help. Please reply to the mailing list.
participants (1)
-
Adam Mizerski