/* dlsym-main.c */

#include 

void doSomething(char const *msg)
{
    fprintf(stderr, "Main program is doing %s\n", msg);
}

void (*fnptr)(char const *) = doSomething;

int main() {

    fnptr("some printing");
    return 0;
}

/* dlsym-lib.c */

#define _GNU_SOURCE  1
#include 
#include 

void myLibraryFunc(char const *msg)
{
    fprintf(stdout, "My library is doing %s\n", msg);
}

void hook(void)
{
    // Load the current executable as a shared object
    void* handle = dlopen(NULL, RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "Error: %s\n", dlerror());
        return;
    }

   typedef void (*fnT)(char const *);

    // Dynamically resolve the global non-static variable
    fnT* fnPtr = (fnT*) dlsym(handle, "fnptr");
    if (!fnPtr)
    {
        fprintf(stderr, "Error locating fnptr: %s\n", dlerror());
        dlclose(handle);
        return;
    }
    *fnPtr = myLibraryFunc;

    // Close the handle
    dlclose(handle);
}

__attribute__((constructor))
void setup() { hook(); }

## Makefile

linky: dlsym-main.c
	gcc -o linky dlsym-main.c
libi.so: dlsym-lib.c
	gcc -shared -fPIC -o libi.so dlsym-lib.c -ldl

run: linky libi.so
	LD_PRELOAD=$$PWD/libi.so ./linky

Output of make run:

Error locating fnptr: Symbol not found: fnptr
Main program is doing some printing

Symbol (fnptr) is a global data object:

> objdump -t linky | grep fnptr
0000000000020008 g     O .data	0000000000000008 fnptr

Using LD_DEBUG=symbols (Debian) shows that it's looking in the executable:

318:	symbol=fnptr;  lookup in file=./linky 
       318:	symbol=fnptr;  lookup in file=/CDS/libi.so 
       318:	symbol=fnptr;  lookup in file=/usr/lib/aarch64-linux-gnu/libstdc++.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libc.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libdl.so.2 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libm.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libgcc_s.so.1 
       318:	symbol=fnptr;  lookup in file=/lib/ld-linux-aarch64.so.1 
       318:	/CDS/libi.so: error: symbol lookup error: undefined symbol: fnptr (fatal)

I've tried this on Debian, Alpine (musl libc), and other variants (all GCC) and the same results occur. I've asked AI bots how to do this and they spit out exactly this code. The same code on macOS works fine

▶ make run_macOS
DYLD_INSERT_LIBRARIES=$PWD/libi.so ./linky
My library is doing some printing

What am I doing wrong that this doesn't work on GCC?

I want to change a path that a program actually opens on filesystem for some paths. The reason is that I want to run a program in parallel, but that program uses /tmp/somedir/ as its temporary directory and parallel instances run into conflicts. I found this great answer to do just that: Is it possible to fake a specific path for a process? . Sadly, while this works for cat as advertised, it does not work for my program. I thought the cause is that the program uses C++ API. To reproduce, I first made a very simple program that writes something in a file:

#include 
#include 
#include 

int main() {
    std::ofstream myfile;
    myfile.open("test.log");
    std::string_view text{"hello world\n"};
    myfile.write(text.data(), text.size());
    return 0;
}

I then used strace and saw this at the end:

brk(NULL)                               = 0x558b5d5e3000
brk(0x558b5d604000)                     = 0x558b5d604000
futex(0x7f94e2e7e77c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "test.log", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(3, "hello world\n", 12)           = 12
close(3)                                = 0
exit_group(0)                           = ?

So it looks like C api is called, but the function used is openat. I also saw this for the C so library, this will be relevant later:

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

So I implemented openat in addition to open, and this is the full program. For test purposes, instead of changing a path I just log it into a file.

/*
 * capture calls to a routine and replace with your code
 * g++ -Wall -O2 -fpic -shared -ldl -lstdc++ -o fake_open_file.so fake_open_file.cpp
 * LD_PRELOAD=/home/myname/fake_open_file.so cat
 */
#define _FCNTL_H 1 /* hack for open() prototype */
#undef _GNU_SOURCE
#define _GNU_SOURCE /* needed to get RTLD_NEXT defined in dlfcn.h */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


// for the test, I just log anything that was open into a new log file
struct open_reporter
{
    open_reporter() = default;
    void report_filename(std::string_view filename)
    {
        std::lock_guard l{file_report_mutex};
        if(!is_open) {
            myfile.open("/home/myname/fileopen.log");
        }
        std::string tmp = std::string{filename} + "\n";
        myfile.write(tmp.data(), tmp.size());
    }
    std::ofstream myfile;
    std::mutex file_report_mutex;
    bool is_open = false;
};

static open_reporter reporter_;

extern "C" {
    int open(const char *pathname, int flags, mode_t mode)
    {
        static int (*real_open)(const char *pathname, int flags, mode_t mode) = nullptr;

        if (!real_open) {
            real_open = reinterpret_cast(dlsym(RTLD_NEXT, "open"));
            char *error = dlerror();
            if (error != nullptr) {
                reporter_.report_filename("ERROR OCCURED!");
                reporter_.report_filename(error);
                exit(1);
            }
        }

        reporter_.report_filename(pathname);
        return real_open(pathname, flags, mode);
    }

    int openat(int dirfd, const char *pathname, int flags, mode_t mode)
    {
        static int (*real_openat)(int dirfd, const char *pathname, int flags, mode_t mode) = nullptr;

        if (!real_openat) {
            real_openat = reinterpret_cast(dlsym(RTLD_NEXT, "openat"));
            char *error = dlerror();
            if (error != nullptr) {
                reporter_.report_filename("ERROR OCCURED!");
                reporter_.report_filename(error);
                exit(1);
            }
        }

        reporter_.report_filename(pathname);
        return real_openat(dirfd, pathname, flags, mode);
    }
}

This works with cat still, but not with my test program. Even if I change open and openat to return 0, while this breaks cat it does not have any effect on my test program. I also checked if the symbols are in my binary:

$ nm -gD fake_open_file.so | grep open
0000000000001470 W _ZN13open_reporterD1Ev
0000000000001470 W _ZN13open_reporterD2Ev
0000000000001450 T open
0000000000001460 T openat

I can see both the functions present. Looking into C library, I see a difference, but I don't know what it means. I redacted things that are not open or openat:

$ nm -gD /lib/x86_64-linux-gnu/libc.so.6 |grep open
0000000000114820 W openat@@GLIBC_2.4
0000000000114820 W openat64@@GLIBC_2.4

0000000000114690 W open@@GLIBC_2.2.5
0000000000114690 W open64@@GLIBC_2.2.5

0000000000114690 W __open@@GLIBC_2.2.5
0000000000114690 W __open64@@GLIBC_2.2.5
00000000001147c0 T __open64_2@@GLIBC_2.7
0000000000119b80 T __open64_nocancel@@GLIBC_PRIVATE
0000000000114660 T __open_2@@GLIBC_2.7
0000000000040800 T __open_catalog@@GLIBC_PRIVATE
0000000000119b80 T __open_nocancel@@GLIBC_PRIVATE
0000000000114950 T __openat64_2@@GLIBC_2.7
00000000001147f0 T __openat_2@@GLIBC_2.7

Apart of the @@GLIBC stuff, these are the same. I never have done this before, so this is as far as my debugging ability goes. I am asking here and not SO because here is where I got the original answer and also this looks more like linux knowledge than a programming problem, the program itself is very simple.

Digging into tcpdump implementation, I can see that it actually loads the libpcap.so dynamic library in userspace. However, by use of strace, I can't see any occurrence of calls to any function exported by libpcap. Is the above an expected behaviour of tcpdump? Thank you. root@eve-ng02:~# tcpdump --help tcpdump version 4.9.2 libpcap version 1.7.4 OpenSSL 1.0.2g 1 Mar 2016 Edit: from received comments I tried with ltrace but it seems no call to dynamic library is done as well. root@eve-ng02:~# ltrace tcpdump -i lo tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes ^C--- SIGINT (Interrupt) --- 0 packets captured 126 packets received by filter 98 packets dropped by kernel +++ exited (status 0) +++ root@eve-ng02:~#

What I already know: An ELF executable has a number of sections, obviously the .text and .data sections get loaded into memory as these are the main parts of the program. But for a program to work, it needs more info, especially when linked dynamically. What I'm interested in are sections like .plt, .got, .dynamic, .dynsym, .dynstr etcetera. The parts of the ELF that are responsible for the linking of functions to addresses. From what I've been able to figure out so far, is that things like .symtab and .strtab do not get loaded (or do not stay) in memory. But are .dynsym and and .dynstr used by the linker? Do they stay in memory? Can I access them from program code? And are there any parts of an executable that reside in kernel memory? My interest in this is mostly forensic, but any information on this topic will help. The resources I've read about these tables and dynamic linking are more high level, they only explain the workings, not anything practical about the contents in memory. Let me know if anything in unclear about my question.

I am trying to make sense of the env variable LD_ASSUME_KERNEL on my system (Debian/bullseye+bpo). Accoring to :

$ man pthreads

I should be able to run something like this, however on my system here is what I get:

% LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls
/bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory

This is somewhat too low level for me to understand what is going on. I fail to understand if LD_ASSUME_KERNEL implementation is somewhat broken on my system, or if I fail to read the documentation properly. Some other failed attempts:

% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.2.5 ldd
        linux-vdso.so.1 (0x00007ffe3f7e0000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f5399001000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found

and

% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.4.19 ldd
        linux-vdso.so.1 (0x00007ffeaacb9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f861cb18000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found

While:

% LD_TRACE_LOADED_OBJECTS=1 ldd
        linux-vdso.so.1 (0x00007ffc929a9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fa319a29000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa319a23000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa31985e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa319aaa000)

References: $ man pthreads [...] Selecting the threading implementation: LD_ASSUME_KERNEL On systems with a glibc that supports both LinuxThreads and NPTL (i.e., glibc 2.3.x), the LD_ASSUME_KERNEL environment variable can be used to override the dynamic linker's default choice of threading implementation. This variable tells the dynamic linker to assume that it is running on top of a particular kernel version. By specifying a kernel version that does not provide the support required by NPTL, we can force the use of LinuxThreads. (The most likely reason for doing this is to run a (broken) application that depends on some nonconformant behavior in LinuxThreads.) For example: bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \ awk '{print $3}' ) | egrep -i 'threads|nptl' linuxthreads-0.10 by Xavier Leroy Same goes for: $ man ld.so [...] LD_ASSUME_KERNEL (since glibc 2.2.3) Each shared object can inform the dynamic linker of the minimum kernel ABI version that it requires. (This requirement is encoded in an ELF note section that is viewable via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run time, the dynamic linker determines the ABI version of the running kernel and will reject loading shared objects that specify minimum ABI versions that exceed that ABI version. LD_ASSUME_KERNEL can be used to cause the dynamic linker to assume that it is running on a system with a different kernel ABI version. For example, the following command line causes the dynamic linker to assume it is running on Linux 2.2.5 when loading the shared objects required by myprog: $ LD_ASSUME_KERNEL=2.2.5 ./myprog On systems that provide multiple versions of a shared object (in different directories in the search path) that have different minimum kernel ABI version requirements, LD_ASSUME_KERNEL can be used to select the version of the object that is used (dependent on the directory search order). Historically, the most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementation on systems that provided both LinuxThreads and NPTL (which latter was typically the default on such systems); see pthreads(7).

% apt-cache policy manpages
manpages:
  Installed: 5.10-1
  Candidate: 5.10-1
  Version table:
 *** 5.10-1 500
        500 http://deb.debian.org/debian  bullseye/main amd64 Packages
        500 http://deb.debian.org/debian  bullseye/main i386 Packages
        100 /var/lib/dpkg/status

--- As a side note, the output is always the same for:

/lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.2.5 /lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.4.19 /lib/x86_64-linux-gnu/libc.so.6

I get:

GNU C Library (Debian GLIBC 2.31-13+deb11u3) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.2.1 20210110.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
.

I wrote different two different types of queues. Bundled them in different .sos. I have a driver main.c which tests functions offered by those queues. main.c makes use dlfcn.h to load, unload required library at run-time. Both the implementations of queue make use of standard library functions. I wish to list number of mallocs and frees made by my library. So I did ltrace -c ./exe.out but, it could not catch any standard library calls made by my dlopen()ed libraries. All that ltrace could tap in was dl*() calls. I checked SEE ALSO part of man ltrace and so read man ltrace.conf too. But the manual itself is bit obfuscated for beginners like me! - How to trace calls made by dlopen()ed libraries using ltrace utility? - Does configuring /etc/ltrace.conf help me deal this situation?

In Linux, what are the executable ELF files respectively for - static linker - dynamic linker - loader - dynamic loader? Which of them are invoked - by execve() - by dlopen()? How are they invoked by execve() or dlopen(), to solve the chicken-egg problem that execve() or dlopen() are used for invoking executable files? Thanks.

My application loads custom code using dlopen on the fly. For common symbols, the global symbol table is used by default. However, I want to provide the functionality where - if the user has linked their so with -Bsymbolic-functions, I pass the RTLD_DEEPBIND flag to the dlopen function. Is there a way I can programmatically know whether a .so is linked with -Bsymbolic-functions or not using C ?

I want to know how I can "give" a forked process a different dynamic library than the one it "asks" for. For example, if the fork "asks" for the library "foo.so" the main process "intercepts" that and instead provides "bar.so". Considering I don't know much about how dynamic libraries are loaded, it's very much possible that this is impossible.

I have a large application (let's call it P) with lots of dependencies to boost, Qt, zlib, libpng, etc. Recently, I have added a feature to P that needs to dynamically load a new shared object (let's call it lib1.so). lib1.so is dependent to MATLAB api. As a result, it will be dependent to lots of libraries that P already is dependent to. The problem is that when I try to dynamically load lib1.so inside P (using the QLibrary class of Qt 5.12), the loading is failed. The failure message is that a Matlab shared object cannot be found. But the shared object is already there and its path is inside LD_LIBRARY_PATH. If I try to load lib1.so inside a simple application (with the same LD_LIBRARY_PATH value) it works fine. My guess is that P is loading a shared object at load time and lib1.so want to load the same library (but a different version) while dynamic loading time and this conflict does not allow lib1.so to be loaded inside P. I have tried to use strace command on P, but because lib1.so is loaded dynamically, it does not help me a lot. What is the best way to find this common library that makes this error?

If one program, for example grep, is curretly running, and a user executes another instance, do the two instances share the read-only .text sections between them to save memory? Would the sharing of the main executable text sharing be done similarly to shared libraries? Is this behavior exhibited in Linux? If so, do other Unices do so as well? If this is not done in Linux, would any benefit come from implementing executables that often run multiple instances in parallel as shared libraries, with the invoked executable simply calling a main function in the library?

I am reading the blog https://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64 In the part "x64 PIC with data references - an example", it seems that the module is telling the dynamic linker to fill the absolute address of myglob into .got, then the code get that address and read data from that address. But why does the compiler have to do this, it's a symbol come from itself, why can't just use RIP-relative addressing to access this symbol? Is it because sometimes .data of the module might be load to a unknown offset to .text(instead of always loaded next to .text)? I mean, if address_of(myglob)-address_of(instruction_that_access_myglob) is a certain value, why do we even have to know the absolute address of myglob?

I have the same exact problem as this question previously posted, where /etc/ld.so.preload does not intercept the right architecture. A little background: I have compiled a shared object (64-bit) that is referenced in the ld.so.preload file on any binary execution. The problem was that I was getting a ERROR: ld.so: object '/usr/local/lib/mysharedobject.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. when executing 32-bit programs. To fix the issue according to the answer in that question, I had to make two directories (lib/i386-linux-gnu and x86_64-linux-gnu, for example, in /var/opt) and specify /var/opt/$LIB/mysharedobject.so in /etc/ld.so.preload so the right library will be preloaded depending in program architecture. So in that case, in Debian based systems, /var/opt/$LIB/mysharedobject.so would expand to: - /var/opt/lib/i386-linux-gnu/mysharedobject.so for 32-bit programs; - /var/opt/x86_64-linux-gnu/mysharedobject.so for 64-bit programs. However, after applying this, any binary I run (such as ls) will output the following 'error': ERROR: ld.so: object '/var/opt/$LIB/mysharedobject.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. As you can see, $LIB did not expand to anything. I have also set $LD_LIBRARY_PATH to /var/opt and ran ldconfig to update the system with this libs, but with no success. What is the problem here?

Operating System Concepts, by Silberschatz A., Galvin P. B., Gagne G. - Operating System Concepts, 9th Edition - 2012 says > **8.1.4 Dynamic Loading** > > In our discussion so far, it has been necessary for the entire program > and all data of a process to be in physical memory for the process to > execute. The size of a process has thus been limited to the size of > physical memory. To obtain better memory-space utilization, we can use > dynamic loading. **With dynamic loading, a routine is not loaded until > it is called.** **All routines are kept on disk in a relocatable load > format.** The main program is loaded into memory and is executed. When a > routine needs to call another routine, the calling routine first checks > to see whether the other routine has been loaded. If it has not, the > relocatable linking loader is called to load the desired routine into > memory and to update the program’s address tables to reflect this > change. Then control is passed to the newly loaded routine. > > The advantage of dynamic loading is that a routine is loaded only when > it is needed. This method is particularly useful when large amounts of > code are needed to handle infrequently occurring cases, such as error > routines. In this case, although the total program size may be large, > the portion that is used (and hence loaded) may be much smaller. > > **Dynamic loading does not require special support from the operating > system. It is the responsibility of the users to design their programs > to take advantage of such a method. Operating systems may help the > programmer, however, by providing library routines to implement > dynamic loading.** > > **8.1.5 Dynamic Linking and Shared Libraries** What kinds of files have "a relocatable load format" in Linux, - an ELF executable file, - a .so shared library file, - a kernel module, - a .o object files? Can they all be dynamically loaded? Does "a relocatable load format" in the quote mean .o object file, a kernel module, but not .so shared library file, according to: - http://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html says there are three kinds of ELF files: executable files, shared object files, and relocatable files. - https://unix.stackexchange.com/questions/476149/what-elf-types-do-kernel-itself-and-kernel-modules-have/476157#476157 shows that a kernel module is also relocatable ELF. The book doesn't mention anything yet about shared library until Section 8.1.5, so Section 8.1.4 seems to me that dynamic loading is not necessarily loading a shared library into a user program, but may load something else. Is that true? The last paragraph of section 8.1.4 seems to say that programmers need to perform dynamic loading explicitly. Does it refer to dlopen()? What kinds of ELF files can dlopen() accepts as its first argument, a .so shared library, a .o object file, a kernel module, an executable ELF file? Thanks.

Understanding the Linux Kernel says > The kernel has two key tasks to perform in managing modules. The first task is mak- ing sure the rest of the kernel can reach the module’s global symbols, such as the entry point to its main function. A module must also know the addresses of symbols in the kernel and in other modules. Thus, **references are resolved once and for all when a module is linked.** The second task consists of keeping track of the use of modules, so that no module is unloaded while another module or another part of the kernel is using it. A simple reference count keeps track of each module’s usage. Is it correct that any shared library can be both dynamically linked (using LD_LIBRARY_PATH), and dynamically loaded (by dlopen(), dlsym() and dlclose())? Is a module a shared library to the Linux kernel? How does Linux kernel dynamically use a module? Is it by dynamic linking (using LD_LIBRARY_PATH), or dynamic loading (by dlopen(), dlsym() and dlclose())?

> **The dynamic linker can be run** either indirectly by running some dynamically linked program or shared object (in which case no command-line options to the dynamic linker can be passed and, in the ELF case, the dynamic linker which is stored in the .interp section of the program is executed) or **directly by running:** > **/lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]** https://jlk.fjfi.cvut.cz/arch/manpages/man/core/man-pages/ld.so.8.en Similar info can be found in [Program Library HOWTO](http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html) . But when I try, $ LD_DEBUG=libs /usr/lib/ld-linux.so.2 ls 23325: find library=ls ; searching 23325: search cache=/etc/ld.so.cache 23325: ls: error while loading shared libraries: ls: cannot open shared object file $ LD_DEBUG=libs ls 23503: find library=libcap.so.2 ; searching 23503: search cache=/etc/ld.so.cache 23503: trying file=/usr/lib/libcap.so.2 ... What am I doing wrong? Is there a way to use ld-linux.so directly to run a program?

In strace outputs, the paths to the libraries that executables call are in calls to open(). Is this the system call used by executables that are dynamically linked? What about dlopen()? open() isn't a call I'd have guessed would play a role in the execution of programs.

So I have a Linux machine that acts as an NFS server. Lots of programs has been installed to the folder that is being exported. On another Linux machine, I've been running one of the program that is sitting in the exported NFS folder for a very long time, and it won't finish soon. It turns out that now I need to do some urgent maintenances work with the network, so the network will be down for a while. I'm wondering what will happen to the running program? My understanding is that the program is loaded to the RAM in a lazy approach. So in the best case, say the program is executing some codes that is a part of loop that has been already loaded into the RAM, then it won't need to access the executable file at all during the period of network interrupt, and the program will just keep executing fine, like nothing happened, right? But, say that, if it turns out that the program do need load some other parts of the executable into the RAM and the network is currently down. Will it "freeze" for a while and then continue to execute fine when the network is up? I'm thinking of this loading process will eventually invoke some io related system call, and those system call will eventually handled by the NFS client library. If the network is down, then NFS client library will just keep retrying for the time period the network is down and then return success when the network is up. So from the perspective of the system, this just seems like a system call takes a really long time. I'm not sure about my reasoning, especially for the part of the loading process. When loading a part of the executable into the RAM, will the OS invoke the io related system call? Or can it bypass the system call and do it in a even lower level approach and then fails, so that the execution of my program will be stop due to the failure? Also, do I need to consider NFS caching policies in reasoning about this? Thanks~!

I installed the mod_qos module using the steps found here , every step went perfectly fine without any problems, however, when attempting to restart the apache service it returned the following error: apache2: Syntax error on line 203 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/qos.load: Cannot load /usr/lib/apache2/modules/mod_qos.so into server: /usr/lib/apache2/modules/mod_qos.so: undefined symbol: EVP_DecryptFinal The contents of the qos.load file is just this line: LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so How do I solve this error?

How can I list all loaded libraries of a process in FreeBSD? On Linux I can use /proc cat /proc/$pid/maps on Solaris there is pldd pldd $pid For FreeBSD /proc also works: cat /proc/$pid/map however, /proc is not mounted by default. As this is used in an autodetection tool on customers' systems, I'm looking for something (tool or file) that works out of the box. I'm assuming there must be an additional interface to process data on FreeBSD because top works even without mounted /proc.