I was following this instruction on this site to installing tesseract: https://github.com/tesseract-ocr/tesseract/wiki/Compiling git clone https://github.com/tesseract-ocr/tesseract.git cd tesseract ./autogen.sh ./configure make sudo make install sudo ldconfig But there is a problem in the last line and I got this error messages when I tried ldconfig: /sbin/ldconfig.real: /usr/local/lib is not a known library type /sbin/ldconfig.real: /usr/local/lib/pkgconfig is not a known library type What's that error meaning and how can I fix it? This is the content of /etc/ld.so.conf.d/libc.conf : # libc default configuration /usr/local/lib

I'm trying to run an app on Fedora 33, but when I run the executable, I get this error:

error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
libGL error: MESA-LOADER: failed to open iris (search paths /usr/lib64/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib64/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  52
  Current serial number in output stream:  51

I tried following the thread here: https://www.reddit.com/r/Fedora/comments/hhytvl/libgl_error_mesaloader_failed_to_open_iris/ but haven't gotten anything to work Note that the driver iris_dri.so is present in both /usr/lib/dri and /usr/lib64/dri Any help is appreciated, thanks in advance!

I'm in an ubuntu 22.04 and have a binary that can't execute because it's missing libssl.so.10: ./nGeMTools ./nGeMTools: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory So after downloading and locally compiling the lib I got the file libssl.so.1.0.0. I made a link to it in /usr/local/lib in the adequate name searched by the binary: /usr/local/lib$ sudo ln -s /usr/local/ssl/lib/libssl.so.1.0.0 libssl.so.10 /usr/local/lib$ ls -lah | grep ssl lrwxrwxrwx 1 root root 34 jun 18 12:14 libssl.so.10 -> /usr/local/ssl/lib/libssl.so.1.0.0 I also confirmed that /usr/local/lib would be searched by ldconfig because its mentioned in /etc/ld.so.conf.d/libc.conf: $ cat /etc/ld.so.conf.d/libc.conf # libc default configuration /usr/local/lib So I guess I don't need to create a new /etc/ld.so.conf.d/libssl.conf file with the same folder name in it. After running ldconfig, ldconfig -v weirdly returns, between other stuff: /sbin/ldconfig.real: Path `/usr/lib' given more than once (from :0 and :0) libssl.so.1.0.0 -> libssl.so.10 /sbin/ldconfig.real: /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 is the dynamic linker, ignoring Which seems to be the inverted link (what I want is libssl.so.10 poiting to libssl.so.1.0.0, not the other way around). Indeed, trying to execute my bynary returns the same error as before. However, if I do the exact same configuration in /usr/lib: /usr/local/lib$ sudo rm libssl.so.1* /usr/local/lib$ cd /usr/lib /usr/lib$ sudo ln -s /usr/local/ssl/lib/libssl.so.1.0.0 libssl.so.10 /usr/lib$ ls -lah | grep ssl lrwxrwxrwx 1 root root 34 jun 18 12:17 libssl.so.10 -> /usr/local/ssl/lib/libssl.so.1.0.0 drwxr-xr-x 3 root root 4,0K maj 16 08:32 ssl /usr/lib$ sudo ldconfig Then ldconfig -v returns, among other stuff: libssl3.so -> libssl3.so libssl.so.3 -> libssl.so.3 libxmlsec1-openssl.so.1 -> libxmlsec1-openssl.so.1.2.33 libssl.so.1.0.0 -> libssl.so.10 Which is still inverted... but now trying to run my binary returns: $ ./nGeMTools ./nGeMTools: error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory which indicates to me that it could load libssl and is now just missing libcrypto. Why is the behaviour different depending on the folders even if /usr/local/lib is on /etc/ld.so.conf.d/libc.conf?

I have an Orange Pi 5, an arm64 SBC running *Joshua Riek's Ubuntu 22.04.4 for RK3588* (link to project ). I'm trying to build Duckstation , a PS1 emulator, which depends on Qt 6.6.2. The latest arm64 Qt version I have available through apt is version 6.2.4. I'm building Qt 6.6.2 from source, but I'm having issues linking the built library to the Duckstation cmake build. ### Building Qt 6.6.2 from git The Qt installer application is not available for arm64, so I followed Qt's documentation on how to build Qt6 from git, found here . The steps I have taken are as follows: 1. Clone the Qt6 repository and switch to 6.6.2 branch

$ git clone git://code.qt.io/qt/qt5.git qt6
$ cd qt6
$ git switch 6.6.2

2. Initialize the submodules with init-repository script

$ perl init-repository

3. Create a build directory and configure

$ mkdir build && cd build
$ ../configure

I left the -prefix attribute out, by default it will be set to /usr/local/Qt-6.6.2 4. Build the whole Qt6 library and install

$ cmake --build . --parallel $(nproc)
$ sudo cmake --install .

Building the full library takes over an hour on this platform. After installing, the contents of the directory /usr/local/Qt-6.6.2 look like this: ### Building Duckstation Following the build instructions on Duckstation's readme, here are the build steps 1. Clone the repository

$ git clone https://github.com/stenzek/duckstation.git  duckstation
$ cd duckstation

2. Create a build directory and configure

$ mkdir build
$ cmake -Bbuild -DCMAKE_BUILD_TYPE=Release

When trying to configure the build, I'm getting an error locating the Qt 6.6.2: **How do I link the built library to the CMake build?** I have tried creating an ldconfig file /etc/ld.so.conf.d/Qt-6.6.2.conf which contains

/usr/local/Qt-6.6.2/bin
/usr/local/Qt-6.6.2/lib

After creating the file, I ran sudo ldconfig. If it's not a linking issue, am I installing the Qt6 to a wrong location, or missing some critical configuration step in the build? As a sidenote: I'm able to build Duckstation successfully by patching the required Qt version to 6.2.4 and by modifying the sources a bit, but I'd like to be able to build the main branches, for handling updates more easily etc.

during an update dnf throw this > ldconfig: File /lib/librav1e.so.0 is empty, not checked. ldconfig: File /lib/librav1e.so.0.6.6 is empty, not checked. ldconfig: File /lib/libnl-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libnl-genl-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-genl-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libnl-idiag-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-idiag-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libnl-nf-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-nf-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libnl-route-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-route-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libnl-xfrm-3.so.200 is empty, not checked. ldconfig: File /lib/libnl-xfrm-3.so.200.26.0 is empty, not checked. ldconfig: File /lib/libSvtAv1Dec.so.0 is empty, not checked. ldconfig: File /lib/libSvtAv1Dec.so.0.8.7 is empty, not checked. ldconfig: File /lib/libSvtAv1Enc.so.1 is empty, not checked. ldconfig: File /lib/libSvtAv1Enc.so.1.4.1 is empty, not checked. ldconfig: File /lib/libnn.so.2 is empty, not checked. ldconfig: File /lib/libnn.so.2.0.0 is empty, not checked. ldconfig: File /lib/libodbc.so.2 is empty, not checked. ldconfig: File /lib/libodbc.so.2.0.0 is empty, not checked. ldconfig: File /lib/libodbccr.so.2 is empty, not checked. ldconfig: File /lib/libodbccr.so.2.0.0 is empty, not checked. ldconfig: File /lib/libodbcinst.so.2 is empty, not checked. ldconfig: File /lib/libodbcinst.so.2.0.0 is empty, not checked. ldconfig: File /lib/libtemplate.so.2 is empty, not checked. ldconfig: File /lib/libtemplate.so.2.0.0 is empty, not checked. ldconfig: File /lib/liborc-0.4.so.0 is empty, not checked. ldconfig: File /lib/liborc-0.4.so.0.33.0 is empty, not checked. ldconfig: File /lib/liborc-test-0.4.so.0 is empty, not checked. ldconfig: File /lib/liborc-test-0.4.so.0.33.0 is empty, not checked. ldconfig: File /lib/libOpenCL.so.1 is empty, not checked. ldconfig: File /lib/libOpenCL.so.1.0.0 is empty, not checked. ldconfig: File /lib/libnss_mdns.so.2 is empty, not checked. ldconfig: File /lib/libnss_mdns4.so.2 is empty, not checked. ldconfig: File /lib/libnss_mdns4_minimal.so.2 is empty, not checked. ldconfig: File /lib/libnss_mdns6.so.2 is empty, not checked. ldconfig: File /lib/libnss_mdns6_minimal.so.2 is empty, not checked. ldconfig: File /lib/libnss_mdns_minimal.so.2 is empty, not checked. ldconfig: File /lib/liblockdev.so.1 is empty, not checked. ldconfig: File /lib/liblockdev.so.1.0.0 is empty, not checked. ldconfig: File /lib/libhwy.so.1 is empty, not checked. ldconfig: File /lib/libhwy.so.1.0.7 is empty, not checked. ldconfig: File /lib/libhwy_contrib.so.1 is empty, not checked. ldconfig: File /lib/libhwy_contrib.so.1.0.7 is empty, not checked. ldconfig: File /lib/libhwy_test.so.1 is empty, not checked. ldconfig: File /lib/libhwy_test.so.1.0.7 is empty, not checked. ldconfig: File /lib/libgd.so.3 is empty, not checked. ldconfig: File /lib/libgd.so.3.0.11 is empty, not checked. ldconfig: File /lib/libsane.so.1 is empty, not checked. ldconfig: File /lib/libsane.so.1.2.1 is empty, not checked. ldconfig: File /lib/libgraphene-1.0.so.0 is empty, not checked. ldconfig: File /lib/libgraphene-1.0.so.0.1000.6 is empty, not checked. ldconfig: File /lib/libcdda_interface.so.0 is empty, not checked. ldconfig: File /lib/libcdda_interface.so.0.10.2 is empty, not checked. ldconfig: File /lib/libcdda_paranoia.so.0.10.2 is empty, not checked. ldconfig: File /lib/libcdda_paranoia.so.0 is empty, not checked. what could cause this and how can I fix it ? I tried to force reinstall some of the packages but nothing has changed.

I have installed some shared libraries to the non-standard directory /usr/lib64/mylib. Then I run sudo ldconfig /usr/lib64/mylib. I can assert by running ldconfig -p that my libraries are indeed cached. However when I try to compile a certain program that links to a library which links to another library installed in /usr/lib64/mylib I get the following error:

/usr/bin/ld: warning: libmy.so.3, needed by ./build/libtools.so.3.1.0.0, not found (try using -rpath or -rpath-link)

along with a number of undefined references. This does not happen if I add /usr/lib64/mylib to either /etc/ld.so.conf or to the environment variable LD_LIBRARY_PATH. So what is then the effect of running sudo ldconfig /usr/lib64/mylib? Edit: I found out that the lines referring to my shared objects get removed when I run ldconfig -p a second time, so they remain there for a very brief moment for some reason.

Ok, I made a mistake and I'm struggling to fix it: I was looking for a libGL.so to link a project, and found it in a (conan-related) package that is mounted during build time. The default system /usr/lib64/libGL.so.1 didn't seem to get picked up (different versions/dependencies?) So I turned to ld.so.config to add the folder containing libGL.so, just under the only other line: include /etc/ld.so.config.d/* /hfs/xyz/conan-package-123/../usr/lib64/ # the line I added then I ran sudo ldconfig and then was greeted by a slew of errors of the form "ldconfig: /hfs/xyz/conan-package-123/../usr/lib64/libGL.so is not a symbolic link" linking still does not work, but worse, I seem to have lost sudo privileges, and can no longer either run sudo ldconfig, su ldconfig or edit/write /etc/ld.so.config. I also tried using local versions from my home-dir for both the config and cache files using the ldconfig flags -f and -C, I don't seem to get my privileges back. For the record, my /etc/passwd file is -rw-r--r-- root root and /etc is drwxr-xr-x root root, and pwck says wck: Permission denied. pwck: cannot lock /etc/passwd; try again later. Should I restart some service for that? Otherwise that would be a true catch 22. What can I do?

I am patching several libraries on my development server to remove unneeded dependencies using the patchelf tool. These get packaged into an RPM and installed on my runtime system. After the install, ldconfig gets called, and strange links are created. The locations of the patched libraries on the runtime system is something like /usr1/blah/lib and a few subfolders. This location and the location of the subfolders is specified in my /etc/ld.so.conf file. When I run ldconfig, a bunch of links with strange names are created, such as: ?N -> libFoo.so ??r? -> libBar.so as well as links whose names are partial function names of functions in the library, e.g. if I do objdump -x and look at the function names, the link will have part of that function as its name. My understanding was that ldconfig looks at the SONAME of the libraries and creates a link with that name. However when I do an objdump -x on all the affected libraries and grep for SONAME, nothing is out of the ordinary, they all end in .so and have none of the weird question marks. ldconfig -v provides no helpful information. Any ideas as to what could be going on? Maybe the SONAME is getting screwed up in some way that I'm missing? Thanks for any help. edit: if I merely remove dependencies as a part of my patching process (e.g. only call patchelf --remove-needed , then this issue doesn't happen. it's only when I use the --add-needed flag. edit 2: If I just add and remove a garbage dependency (e.g. patchelf --add-needed garbage libFoo.so followed immediately by patchelf --remove-needed garbage libFoo.so), that causes the weird link issue as well. The final dependency list in each library is the exact same, and it works when I just use the --remove-needed flag, which leads me to think that the issue is the --add-needed flag and whatever patchelf does to the header when it does that. edit 3: at this point I am going with the assumption that this is a bug with either patchelf or ldconfig. I'm guessing it's the latter since we're using glibc version 2.17 which is from ~2012, but the latest version of patchelf. perhaps the ELF standard has changed. tl;dr with patchelf version 0.10 and glibc version 2.17, the --add-needed option appears to mess with the ELF such that ldconfig is creating some wonky links.

**TL;DR** Why is it better to place a symlink to a shared library at /etc/lib(64)/ or why is it better to create a *.conf file in /etc/ld.so.conf.d/ --- ## .conf file Assuming i have my custom binary at /opt/foo/, shipping with it's own shared libraries. The common way (known to me) is to place a file at /etc/ld.so.conf.d/foo.conf like follows:

# Link foo libraries. This file is included in /etc/ld.so.conf
/opt/foo/lib
/opt/foo/otherlibs

and run ldconfig afterwards. ## symlinks But I found out that I can also link my libraries into /usr/lib (or lib64) like this:

for f in /etc/foo/{lib,otherlibs}/*; do
  ln -s $f /usr/lib64/$(basename $f)
done

and I won't have to run ldconfig afterwards. **What are the pros/cons of these two ways?** I can imagine that the "symlink"-way isn't very nice to handle when uprading the application or the library versions. In general, the ".conf"-way seems more modular and more Linux-ish to me. I occasionally came across this because we have to encrypt (and only decrypt at runtime) a specific library. ldconfig doesn't recognize the library when encrypted (still in ELF format) so the only suitable way to me was to place a link to the specific *.so file in /usr/lib64

I am working on an **Fedora-34** ssh server and I don't have root access. So I was trying to compile and install the following tool: % git clone https://github.com/google/sentencepiece.git % cd sentencepiece % mkdir build % cd build % cmake .. % make -j $(nproc) % sudo make install % sudo ldconfig -v For the last two lines I couldn't use sudo. So what I did is that I created a bin folder in my $HOME, and again run the following: % git clone https://github.com/google/sentencepiece.git % cd sentencepiece % mkdir build % cd build % cmake .. -DCMAKE_INSTALL_PREFIX:PATH=$HOME/bin/ % make -j $(nproc) % make install % ldconfig -v However, when I run the last command I get the below error: ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied

I have a symlink of the vim.basic executable:

⤷ ls -l /etc/alternatives/vim
lrwxrwxrwx 1 root root 18 Apr 22 21:02 /etc/alternatives/vim -> /usr/bin/vim.basic

Another symlink to the above symlink as:

⤷ ls -l /usr/bin/vim         
lrwxrwxrwx 1 root root 21 Apr 22 21:02 /usr/bin/vim -> /etc/alternatives/vim

They are system configured as I would expect from update-alternatives and I haven't changed anything except I boot sometimes from linux kernel 5.4 or generally from 4.15 using the same root and home partition and this probably what created a problem running vim with sudo?:

⤷ sudo vim.basic                #This works fine!
⤷ sudo /etc/alternatives/vim    #This works fine!
⤷ sudo vim      
vim: error while loading shared libraries: libncurses.so.6: cannot open shared object file: No such file or directory

libncurses.so is installed in a path pointed to by LD_LIBRARY_PATH:

⤷ echo $LD_LIBRARY_PATH
/home/akd/dotapps/local/lib:

⤷ ls -l /home/akd/dotapps/local/lib/libncurses.so.6
lrwxrwxrwx 1 akd akd 17 Nov  9 21:24 /home/akd/dotapps/local/lib/libncurses.so.6 -> libncurses.so.6.2

I can't seem to understand why the double symlink cannot find the libcurses.so.6 on sudo vim operation. Normal vim binary without sudo works as expected though (doesnt compain about ncurses lib).

⤷ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 16 2021 13:33:23)
⤷ sudo --version
Sudo version 1.8.21p2
Sudoers policy plugin version 1.8.21p2
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.21p2

Any idea, why this weird behavior? Update: Adding more info as req:

⤷ ldd $(which vim)        
	linux-vdso.so.1 (0x00007ffc9a2a6000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9d5e059000)
	libncurses.so.6 => /home/akd/dotapps/local/lib/libncurses.so.6 (0x00007f9d5ddee000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9d5dbea000)
	libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f9d5d53f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9d5d320000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d5cf2f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9d5e909000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f9d5ccfd000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9d5cae0000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f9d5c8dd000)

I need to use swrast_dri.so for Flutter but ldconfig is not locating it nor than others libs in /usr/lib/x86_64-linux-gnu. Here my x86_64-linux-gnu.conf file:

# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

My ld.so.conf file:

include /etc/ld.so.conf.d/*.conf

swrast_dri.so is under /usr/lib/x86_64-linux-gnu/dri/ Here a little part of ldconfig -p:

libGLX.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGLX.so.0
	libGLU.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGLU.so.1
	libGLEW.so.2.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGLEW.so.2.1
	libGLESv2.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGLESv2.so.2
	libGL.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGL.so.1
	libFLAC.so.8 (libc6,x86-64) => /lib/x86_64-linux-gnu/libFLAC.so.8
	libEGL_mesa.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libEGL_mesa.so.0
	libEGL.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libEGL.so.1
	libDeployPkg.so.0 (libc6,x86-64) => /usr/lib/libDeployPkg.so.0
	libCoinUtils.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libCoinUtils.so.3
	libCoinMP.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libCoinMP.so.1
	libClpSolver.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libClpSolver.so.1
	libClp.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libClp.so.1
	libCgl.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libCgl.so.1
	libCbcSolver.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libCbcSolver.so.3
	libCbc.so.3 (libc6,x86-64) => /lib/x86_64-linux-gnu/libCbc.so.3
	libBrokenLocale.so.1 (libc6,x86-64, Système d'exploitation ABI : Linux 3.2.0) => /lib/x86_64-linux-gnu/libBrokenLocale.so.1
	libBrokenLocale.so.1 (libc6, Système d'exploitation ABI : Linux 3.2.0) => /lib32/libBrokenLocale.so.1
	libBrokenLocale.so (libc6,x86-64, Système d'exploitation ABI : Linux 3.2.0) => /lib/x86_64-linux-gnu/libBrokenLocale.so
	ld-linux.so.2 (ELF) => /usr/lib/ld-linux.so.2
	ld-linux.so.2 (ELF) => /lib32/ld-linux.so.2
	ld-linux-x86-64.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

As you can see I don't get any libs from usr/lib/x86_64-linux-gnu I already tried to delete ld.so.cache file and rebuild it with ldconfig command but it didn't change anything... ([Here](https://github.com/flutter/flutter/issues/76178) why I need swrast_dri.so)

I'm trying to build a dockerfile for installing saprfc on an Alpine linux base image. The instructions say to create /etc/ld.so.conf.d/nwrfcsdk.conf and to put /usr/local/sap/nwrfcsdk/lib in the nwrfcsdk.conf file. ldconfig should then load the saprfc libraries. However, I have learned that ldconfig on Alpine does not read from ld.so.conf.d. ldconfig -p is also not a recognized option. So how do you add a custom library search path on Alpine Linux?

I am running centos 6.10 in docker. As is described in the title, I set /usr/local/lib and /usr/local/lib64 in a conf file in /etc/ld.so.conf.d/. I need to run ldconfig everytime when I put .so library into /usr/local/lib or it will not be found (when compiling Python 3). However, setting LD_LIBRARY_PATH to /usr/local/lib:/usr/local/lib64 (without writing them to conf files in /etc/ld.so.conf.d/) does not need any additional steps after putting the libs. What causes this? By the way, why directories like /lib and /usr/lib are not set in /etc/ld.so.conf or /etc/ld.so.conf.d/?

On Fedora 33, I'm trying to compile ImageMagic from git. libx265 and libheif are installed from the Fedora fusion repos, along with their -devel packages. When running ./configure --prefix=$HOME --program-prefix=p_ I get these reports:

HEIC              --with-heic=yes		yes
  ...
  LIBS            =  -ljbig  -ltiff -lfreetype  -lraqm -lfreetype  -ljpeg   -llqr-1 -lglib-2.0  -lpng16 -lz    -lfftw3    -lfontconfig -lfreetype  -lheif  -lwebpmux -lwebpdemux -lwebp  -lwebp    -lXext -lXt   -lSM -lICE -lX11  -llzma  -lbz2 -lIlmImf -lImath -lHalf -lIex -lIexMath -lIlmThread -pthread  -lopenjp2  -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo    -lxml2   -lz  -lz      -lm    -lpthread 
  ...
  DELEGATES       = bzlib fftw fontconfig freetype heic jbig jng jpeg lqr lzma openexr openjp2 pango png ps raqm tiff video webp x xml ziplib zlib zstd

After compiling the binary is linked to the wrong libx265.so, though:

% ./p_magick --version
./p_magick: error while loading shared libraries: libx265.so.169: cannot open shared object file: No such file or directory

ldd on the binary (p_magic in my case) reveals:

libx265.so.169 => not found

*(The compiling process is the standard ./configure, make, make install)* This is confusing to me, because libx265.so is installed:

% ll /usr/lib64/libx265*
lrwxrwxrwx 1 root root   14 08-19 03:29 /usr/lib64/libx265.so -> libx265.so.192*
-rwxr-xr-x 1 root root 4.6M 08-19 03:29 /usr/lib64/libx265.so.192*
-rwxr-xr-x 1 root root 5.6M 08-19 03:29 /usr/lib64/libx265_main10.so.192*
-rwxr-xr-x 1 root root 5.5M 08-19 03:29 /usr/lib64/libx265_main12.so.192*

For some reason, p_magick is linked to libx265.so.169 but on my system, libx265.so.192 is installed, I don't quite see how it could be linked to the wrong library, also, I'm struggling to find a mention of libx265 anywhere in the ImageMagick codebase (I've grep-ed for it, etc.). That's why I'm pretty sure the error is not with ImageMagick, but with my system configuration, but I'm not sure where to start. ---- **Addendum** I've deleted /etc/ld.so.cache and re-created the cache with ldconfig. ldconfig -p shows:

# ldconfig -p | grep libx265
	libx265_main12.so.192 (libc6,x86-64) => /lib64/libx265_main12.so.192
	libx265_main10.so.192 (libc6,x86-64) => /lib64/libx265_main10.so.192
	libx265.so.192 (libc6,x86-64) => /lib64/libx265.so.192
	libx265.so (libc6,x86-64) => /lib64/libx265.so

The link inside /lib64 also seems to be correct:

# ll /lib64/libx265.so           
lrwxrwxrwx 1 root root 14 Aug 19 03:29 /lib64/libx265.so -> libx265.so.192

The error still persists, though.

I'm migrating a company-made program, who depends on a couple of also company-made libs (among other libs, of course) to a new server. In the current (old) server (RHEL 5), the lib is in /usr/lib64, but in the new server (RHEL 7), we want to put it in a non-system directory. So I put this lib in /usr/local/lib64 (together with other needed libs), inserted the path /usr/local/lib64 in file /etc/ld.so.conf.d/custom-libs.conf and ran "ldconfig -v" to update the OS' cache. All libs are correctly found, except by one of the custom made. The ldd command also fails to find the lib:

# ldd custom_program | grep custom_lib
    custom_lib.so => not found

But if I run the command with var LD_LIBRARY_PATH as /usr/local/lib64, it works:

# LD_LIBRARY_PATH=/usr/local/lib64 ldd custom_program | grep custom_lib
    custom_lib.so => /usr/local/lib64/custom_lib.so (0x0000...)

It also works if I put the lib (or a symlink) on /usr/lib64, but I really want to keep this as a last resort.

I often build various libraries from source code to play with, such as gmp-6.1.2, mpfr-4.0.1, and gcc-7.x. In doing so, I prefer to use --prefix=/usr/local/gcc-7.2.0 so I know exactly where it is installed and does not mess up existing libraries. And then I all I basically know is what make install tells me at the end, to update or set LD_LIBRARY_PATH and sometimes but not always LD_RUN_PATH. most of the time I just manually set LD_LIBRARY_PATH as needed later on, or set it globally in something like /etc/bash.bashrc.local and that has worked. This is what make install says: Libraries have been installed in: /usr/local/mfprtest/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the '-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the 'LD_RUN_PATH' environment variable during linking - use the '-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to '/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. Is there a better way, **or a more offical way?** of using ldconfig and ld.so.conf than using LD_LIBRARY_PATH and LD_RUN_PATH, and PATH? This is specifically for writing my own code, but could be for other users, where I want to link against various newer versions of a library than what's installed with a given linux version, such as gmp, mpfr, and then using various manually installed versions of gcc such as gcc-5.x or gcc-6.x or gcc-7.x. basically, once I install /usr/local/gcc-7.3.0 for example, I want myself and any other user who either writes or runs home grown c, c++, or fortran source code on the system to use /usr/local/gcc-7.3.0 and not the system versions in /usr/bin/ and /usr/lib64/

using strace I have found a behaviour of ldconfig (glibc), I can make no sense of lstat("/usr/lib/libext2fs.so.2", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0 unlink("/usr/lib/libext2fs.so.2") = 0 symlink("libselinux.so.1", "/usr/lib/libext2fs.so.2") = 0 Is there any need to have the shared object library for ext2fs (libext2fs.so.2) to be a symbolic link to libselinux.so.1. How does ldconfig know what to do? It does not seem logical to me that this static binary /usr/bin/ldconfig would have such a behaviour hardcoded, right. However its configuration file /etc/ld.so.conf does not help me much to clear that mystery. What makes all of this even more confusing/suspicious with my distros tools (Arch Linux) I cannot find any package the file belongs to. $ pkgfile /usr/lib/libselinux.so.1 does not show any package, while $ pkgfile /usr/lib/libext2fs.so outputs core/e2fsprogs So my question is specifically: 1. what the role of this libselinux.so.1 is here 2. how ldconfig comes to decide to create that symlink (which btw. breaks e2fsck)

I am trying setup wireless network. I referred to Cross Compiling iw_wpa_supplicant_hostapd_rfkill for ARM . In the iw part, he used ldconfig -v, but it is not in my rootfs. I searched my busybox, but could not find it. How to get the ldconfig command?