Tag Info

New answers tagged


LD_LIBRARY_PATH settings are dropped by sudo for the security. To avoid being affected by that, you could add those paths to dynamic loader's global search path list. Put the library path lines in /etc/ld.so.conf.d/bitnami.conf: /opt/bitnami/common/lib /opt/bitnami/apache2/lib /opt/bitnami/sqlite/lib /opt/bitnami/subversion/lib Then update ...


The problem was indeed in my toolchain settings. Inspecting the library with objdump revealed the root cause: $ objdump -p libGL.so.1 |grep SONAME SONAME libGL.so.1.2.0 ldd showed both libGL.so.1 and libGL.so.1.2.0, because the first one was imported by glxgears and the second one was imported by my implementation of libGLU which was build ...


I had the same error. The simplest way to solve it is to simply remove all jdks and jres and also the executable /usr/bin/java, if it's there. And then reinstall jdk. It solved the problem for me. While other methods didn't.


Have you considered installing a new system on a different HD (or within a VM) with the same packages you have right now on your Fedora 20 and then copying over from there your entire /var and /usr directories?


If you don't trust the executable, use readelf -d instead. From the ldd man page: In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library dependencies. Be aware, however, that in some circumstances, some versions of ...

Top 50 recent answers are included