polybar: Cannot open shared object file libjsoncpp.so

I was able to solve this on Arch 5.2.14-arch2-1-ARCH using yay. I simply ran yay -S polybar, waiting for the reinstallation/compilation to finish, and polybar was back to working as expected (for me at least).

@ginglis13 Yeah, because, just as it was mentioned multiple times before, recompiling fixes the issue.

Same thing again - libjsoncpp was updated. Recompiling fixes the issue.

This problem just popped up again.

@PonasKovas I think this is why:

https://github.com/polybar/polybar/wiki/Known-Issues#error-while-loading-shared-libraries-libjsoncpp

You have to recompile polybar, see #871

I just had the same problem. Reinstalling polybar worked for me. Thanks.

When jsoncpp introduces possibly breaking changes to its library, it will bump the so called SONAME field in the library. If you compiled polybar with jsoncpp 1.8.4, polybar was linked against libjsoncpp.so.20. So everytime the polybar exectuable is run, the operating system will search for the libjsoncpp.so.20 file for dynamic linking. Now if you update jsoncpp to version 1.9.1, which comes with libjsoncpp.so.21, the OS can no longer find libjsoncpp.so.20 when running polybar and will crash with the mentioned error message.

This is neither a bug in polybar nor in jsoncpp @Jezorko. This is one of the downsides of polybar not being pre-packaged on many platforms because you can update jsoncpp without needing to re-link polybar.

The fix for it didn’t change. You have to recompile polybar.

On Fri, Feb 2, 2018, 03:36 Dessalines notifications@github.com wrote:

This problem just popped up again.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/jaagr/polybar/issues/885#issuecomment-362468146, or mute the thread https://github.com/notifications/unsubscribe-auth/ACVqRgjUTeHpzWTf5I1NJ-4Yt5DnFbqWks5tQnS2gaJpZM4Q0Q3c .

Already got the same problem few months ago and completely reinstalling from the AUR worked well but this time it doesn’t fix the problem, I’ve tried with polybar and polybar-git polybar: error while loading shared libraries: libjsoncpp.so.22: cannot open shared object file: No such file or directory

@Cory-Watson

Why is it that polybar links to libjsoncpp.so.XX instead of libjsoncpp.so?

This is guided by linker internals. If you link to a shared library, the linker will actually link to the SONAME which is libjsoncpp.so.XX, nothing we can do about that I think.

Also linking directly to libjsoncpp.so isn’t a good idea because the whole point of SONAME is to prevent running an executable with a library that is incompatible (has a different SONAME). For that reason creating the symlink is also not a good idea. In the case of jsoncpp it’s probably fine, but imagine libjsoncpp.so.21 is completely different from libjsoncpp.so.20, now you run polybar which is linked to libjsoncpp.so.20 with the symlink that points to libjsoncpp.so.21. In the best case, polybar won’t even start because of a linker error, in the worst case the calls that polybar makes to jsoncpp have malformed inputs and produce unexpected outputs or undefined behavior.