compile-time ^ run-time linking describes the “magic” of linking *.so files with some a.out at runtime, This is more unknown and “magical” than compile-time linking.

“Linking is often referred to as a process that is performed when the executable is compiled, while a dynamic linker is a special part of an operating system that loads external shared libraries into a running process”

I now think when the technical literature mentions linking or linker I need to ask “early linker or late linker?”

Can file get loaded 5min after process starts@@

Q: Can some shared library file get loaded 5 min after my process pid123 starts? says NO. This file has to be loaded into pid123 memory (then dynamically linked into the executable) before main() is called.

Among the 3 major mechanism 1) static linker 2) dynamic linker 3) dlopen, dlopen is able to achieve this purpose but I’m unfamiliar with dlopen.

If pid123 reads a config file to decide whether to load, then dlopen is the only solution. I saw such an industrial strength implementation in 2019.

A remotely related note — The same stackoverflow webpage also shows that after pid123 starts, you can actually remove (and replace) without affecting pid123, since the old file content is already loaded into pid123 memory.

LDLibPath ^ classpath

See also compile-time ^ run-time linking

Q: when I run the a.out, where does the runtime linker search for those *.so files?

Now I know the a.out file remembers/stores the dependency *.so file locations. Suppose a.out remembers was loaded from ~/a/b/c. At runtime, the linker will try ~/a/b/c/  but likely fail… completely normal. clearly explains that *.so file locations can be saved in a.out as a ‘runpath’. The 2nd-best solution is the ldLIbPath env var. lead me to the -R and -rpath linker-options. describes q[ -rpath ] linker option

A c++ executable like a.out using dynamic lib is comparable a java main class using a bunch of jar files.

q[cannot open shared object file]

strace -e trace=open myprogram can be used on a working instance to see where all the SO files are successfully located.

— Aug 2018 case: in QA host, I hit “error while loading shared libraries: … No such file or directory”

I can see this .so file so I used LD_LIBRARY_PATH to resolve it.

Then I get “error while loading shared libraries: … No such file or directory”. I can’t locate this .so, but the same executable is runnable in a separate HostB. (All machines can access the same physical file using the same path.)

I zoomed into the HostB and used “ldd /path/to/executable”. Lo and behold, I can see why HostB is lucky. The .so files are located in places local in HostB … for reasons to be understood.

— May 2018 case:

The wording should be “cannot locate ….”

I fixed this error using $LD_LIBRARY_PATH

The *.so  file is actually specified as a -lthr_gcc34_64 option on the g++ command line, but the file was not found at startup.

I managed to manually locate this file in /a/b/c and added it :



This is related to q[cannot open shared object file]

See for the RUNPATH

q(objdump) can inspect the binary file better than q(ldd) does.

q(ldd) shows the final, resolved path of each .so file, but (AFAIK) doesn’t show how it’s resolved. The full steps of resolution is described in

q(objdump) can shed some light … in terms of DT_RUNPATH section of the binary file.