Ldconfig Only Links Files Starting with Lib*

ldconfig loading only .so files

Found the answer here. The Solution was simple: make a copy that matches the pattern.

cp /usr/local/lib/libdnet.1.0.1 /usr/local/lib/libdnet.so.1.0.1

A less preferred alternative:

$ LD_LIBRARY_PATH=/usr/local/lib
$ export LD_LIBRARY_PATH

ldconfig includes libraries from default path also when i have a customized ld- me .so.conf

Because that is the defined behavior of ldconfig:

ldconfig creates the necessary links and cache to the most
recent shared libraries found in the directories specified on the
command line, in the file /etc/ld.so.conf, and in the trusted
directories (/lib and /usr/lib). The cache is used by the run-time
linker, ld.so or ld-linux.so. ldconfig checks the header and
filenames of the libraries it encounters when
determining which versions should have their links updated.

The trusted directory list was probably updated with lib64 dirs sometime after the man page I cut'n'pasted from was written.

You could create a directory structure based on your conf file with symlinks or bind mounts pointing to the real directories and then use
-r directory to make ldconfig build based on empty versions of the system directories.

how can i solve ldconfig create link with version number

I can't use -lboost_signals when use g++ to compile the source code.

But -L/a/lib/dir/ -lboost_signals is ok.

LD_LIBRARY_PATH and /etc/ld.so.conf.d control the behaviour of the run-time linker ld.so only and do not affect the linking of the object files and libraries done by ld, this is why -L/a/lib/dir/ must be used.

There is no config file or environment variable to add to ld linker path. People normally hard-code extra linker paths in the makefile. Makefiles often consider LDFLAGS environment variable though.

ldconfig: *.so* is not a symbolic link

Common practice is to make symbolic links to relate the library version and soname to the name used when building/linking a program. Here are a few comments on that:

• Program Library HOWTO: 3. Shared Libraries
• “soname” option for building shared library

ldconfig expects that there is only one actual file. Here are a few places where this question has been asked:

• Always getting “not a symbolic link” message, while installing any package
• ldconfig : /usr/lib/libstdc++.so.6 is not a symbolic link + mysql

Usually, problems in this area are due to improper updating of the symbolic links. But an incorrect build-script can be the problem as well.

How can I register my library libfoo.so to link it with `-lfoo`?

If your library is not in a "standard" library directory such as (eg. /usr/local/lib or /usr/lib) then you'll need to tell the compiler it's location -L when you link it -l:

$ gcc -L/home/username/foo -Wall -o test main.c -lfoo
        |                                        |
        |__ location of libfoo.so or libfoo.a    |__ link libfoo.so or libfoo.a

GCC assumes that all libraries start with ‘lib’ and end with .so or .a
(.so is for shared object or shared libraries, and .a is for archive,
or statically linked libraries).

• -L is the location to search for libraries linked to your executable

• -l links the library to the executable (-lfoo can be translated as "link library libfoo.so")

When using shared libraries sometimes simply linking them is not enough (eg. if the library is not installed in a standard location such as the example shown above). This is where using LD_LIBRARY_PATH, rpath or ldconfig comes into play. Static library paths won't need to be set like shared libraries since they are compiled with the executable.

LD_LIBRARY_PATH

$ export LD_LIBRARY_PATH=/home/username/foo:$LD_LIBRARY_PATH

Exporting this variable informs the run-time linker to look in the specified location for the libfoo.so library that's associated with the executable. LD_LIBRARY_PATH is more or less a temporary, or convenient way of setting a library's location.

rpath

$ gcc -L/home/username/foo -Wl,-rpath=/home/username/foo -Wall -o test main.c -lfoo

rpath works similarly to LD_LIBRARY_PATH (as libraries can reside almost anywhere in userland), however, rpath is linked to the executable at compile time, and sets a "fixed" library location.

ldconfig

Ultimately what might be the best solution is to use ldconfig, which creates the necessary links and cache to the most recent shared libraries found in the standard library locations and ones you can specify. It does require elevated permissions (eg. sudo) to set paths up this way, and should be used with a certain degree of caution.

$ sudo cp /home/username/foo/libfoo.so /usr/local/lib
$ sudo chmod 0755 /usr/local/lib/libfoo.so

This copies the library into /usr/local/lib with permissions set to be readable by everyone.

$ sudo ldconfig
$ ldconfig -p | grep foo
libfoo.so (libc6) => /usr/local/lib/libfoo.so

Then we update the loader cache, and verify the path is set correctly.

$ gcc -Wall -o test main.c -lfoo

By using ldconfig, the -L option, LD_LIBRARY_PATH or rpath now shouldn't be needed.

---

_{Additional Information}

↳ Shared Libraries With GCC on Linux

ldconfig command reverts to previous library version

You can add your current lib path to etc/ld.so.conf and then run ldconfig again.

Or you can add to LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/new/path/newpath

---

Related Topics