dlopen isn't a system call, it's a library function in the libdl library. Only system calls show up in strace.
On Linux and on many other platforms (especially those that use the ELF format for executables), dlopen is implemented by opening the target library with open() and mapping it into memory with mmap(). mmap() is really the critical part here, it's ...
You don't need to. Add the directory to /etc/ld.so.conf or a new file in /etc/ld.so.conf.d/, depending on distro.
After that, you must run (at least on Redhat) ldconfig as root.
As a word of caution, you need to be careful which libraries you add to the system shared library path (via the environment, ld.so.conf, or putting in /usr/local/lib). In ...
The following is a really good reference: http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/. It contains a bibliography at the end of a variety of different references at different levels. If you want to know every gory detail you can go straight to the source: http://www.akkadia.org/drepper/dsohowto.pdf. (Ulrich Drepper wrote the Linux ...
I suppose we're talking about x86 architecture.
You cannot have Self-Modifying Code in protected mode, which is used by most UNIX-based operating systems (and not only) that I'm aware of, because the code segments are always read-only. A loader does not control that -it is something that is being handled by the memory management subsystem of the kernel.
dlopen has nothing to do with shared libraries as you think of them. There are two methods of loading a shared object:
You tell the compile-time linker (ld, though usually it's called through the compiler) that you want to use functions from a particular shared library. With this approach, you must know what the name of the library will be at when the ...
In your ld.so.preload, you want to specify "$LIB" in your path rather than an explicit "lib" or "lib64". Thus, on a Redhat-style distro, "/usr/alternates/$LIB/libfoo.so" becomes "/usr/alternates/lib/libfoo.so" for a 32-bit process and "/usr/alternates/lib64/libfoo.so" for a 64-bit process. On an Debian-style distro, "/usr/alternates/$LIB/libfoo.so" becomes "/...
I take it you’re using Jeff Darcy’s definitions:
static linking involves resolving symbols at compile time, whereas dynamic linking involves resolving them at run time;
static loading involves mapping executables and libraries at load time, whereas dynamic loading involves mapping libraries after the process has started.
It doesn’t really make sense to try ...
Today, most operating systems use the method for shared libraries introduced in late 1987 by SunOS-4.0. This method is based on mapping memory via mmap().
Given the fact that in the early 1990s, Sun did even donate the old a.out based code (Solaris at that time was already ELF based) to the FreeBSD people and that this code later was handed over to many ...
procstat is your friend.
You get the info for a specific pid using:
procstat -v $pid
Or if you want for all processes then simply:
It yields an output like this:
$ procstat -v 61303
PID START END PRT RES PRES REF SHD FL TP PATH
61303 0x400000 0x438000 r-x 46 47 2 0 CN-- vn /usr/...
ltrace -S analysis of a minimal example shows that mmap is used in glibc 2.23
In glibc 2.23, Ubuntu 16.04, running latrace -S on a minimal program that uses dlopen with:
ltrace -S ./dlopen.out
dlopen("libcirosantilli_ab.so", 1 <unfinished ...>
SYS_open("./x86_64/libcirosantilli_ab.so", 524288, 06267650550) = -2
This means that mod_qos is trying to use a part of a library that is not (yet) loaded or available. EVP_DecryptFinal should be a part of openSSL, so provided that you've got mod_ssl installed, try loading it before you load qos.
Not easily. ld.so.conf files have a very simple format: they're just a list of paths.
You could do something by building your executable with a different interpreter; the normal one would be something like /lib64/ld-linux-x86-64.so.21 and is what's actually responsible for performing the dynamic linking. So your custom dynamic linker could look in a ...
strace reports on system calls (i.e. functions implemented directly by the kernel). Dynamic libraries aren't a kernel function; dlopen is part of the C library, not the kernel. The implementation of dlopen will call open (which is a system call) to open the library file so it can be read.
Is it correct that any shared library can be both dynamically linked (using LD_LIBRARY_PATH), and dynamically loaded (by dlopen(), dlsym() and dlclose())?
Yes. The difference is that dynamic linking is driven by the dynamic linker, and by the time the program starts (from the program author’s perspective), the libraries have been linked and all the symbols ...
Unix shares executables, and shared libraries are called shared (duh...) because their in-memory images are shared between all users.
I.e., if I run two instances of bash(1), and in one of them run, say, vim(1), I'll have one copy each of the bash and the vim executables in memory, and (as both programs use the C library) one copy of libc.
But even better: ...
No. Dynamic linking isn't part of the libc in the sense of /lib/libc.so.6, it is the functionality of the /lib/ld.so (both of them got a little bit changed file name and path in the last years, but the essence is the same).
Yes, ld.so, the dynamic linker is a shared library as well. Loading it is the first thing what most linux binary does, yet before ...
The shell would expand $LIB, but it was not possible when you did this:
specify /var/opt/$LIB/mysharedobject.so in /etc/ld.so.preload
The manual page mentioning /etc/ld.so.preload doesn't mention the possibility of glob-expansions or environment variables:
File containing a whitespace-separated list of ELF shared
objects to be loaded before the ...
When you execute the command given in the question:
LD_LIBRARY_PATH=$PATH_TO_MY_CUSTOM_LIBC bash -c 'foo'
The executed bash uses the libc provided in the path $PATH_TO_MY_CUSTOM_LIBC if there is one there. It's the linker/loader which honours that environment variable.
The command that is executes inside that bash (you called it foo) will use the libc that ...
Your understanding is not exactly correct, but it's pretty close. The program is indeed loaded lazily, page by page. (Some of it may in fact be loaded before use, but that's a performance-memory trade-off, not something you can count on.)
The part of the system that does the loading is the kernel itself. A page is loaded at the latest when the program ...
For the majority of cases, you can use ldd to determine the libraries an executable is linked against.
# ldd /usr/bin/xz
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fd6a1358000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd6a1138000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd6a0d88000)
ELF DSOs may use a flag (DF_TEXREL) to announce that they require rellocations by modification of their text section (which is normally read-only). The jump table approach along with PIE position independent code should be more optimal, though.
(Found that in http://www.akkadia.org/drepper/dsohowto.pdf, but other resources mention this too).
In an email from Peter Hutterer, who maintains a lot of the Xorg input stack:
right now, you can't unload a module without restarting the server.
patches to support that were floating around at some point but never