New answers tagged

2

You're picking up /usr/local/lib/libvmtools.so.0 which is presumably a remnant of a build done on Debian 6 (which had libicu44). If you rename that out of the way, vmtoolsd should find its libraries properly.


1

I'll try to answer all three parts of this question for you [Why is it] necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behavior installation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATH Linked libraries are referenced ...


5

ldconfig can list all the libraries it has access to. These libraries are also stored in its cache. /sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you're a non-root user). It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what ...


1

All programs try to open /etc/ld.so.preload, this behavior is baked into Glibc. But they only try to open it if it exists (Glibc first calls access). Normally /etc/ld.so.preload doesn't exist, so each process just calls access, gets a negative answer and moves on. This doesn't trigger anything from AppArmor. But if the file exists, then the processes call ...


0

I have run into this a number of times, trying to port code from one Linux system to another. Usually I just end up grep'ing all the standard directories. I couldn't find anything googling. So here is a quick script: edt11x/findinsharedlibs



Top 50 recent answers are included