Dlopen with Two Shared Libraries, Exporting Symbols

How to export symbols from POSIX shared library and load using dlopen, dlsym

In your example, you wrote if (so = nullptr) {, which assigns nullptr to so, and the condition is always false. -Wall is a good idea when debugging!

This alone explains why you can't load the symbol, but I also found that I needed to do dlopen("./foo.so", RTLD_NOW); because dlopen otherwise searches library paths, not the current directory.

Linux and shared libraries, linking vs dlopen - symbol visibility

Your question is exceedingly unclear.

If you dlopen the library, then about the only way to get to any of its symbols is via dlsym.

However, if you dlopen a library with RTLD_GLOBAL, then its symbols become available for subsequently loaded libraries without using dlsym.

For example, if libfoo.so defines symbol foo, and if you dlopen("libfoo.so", RTLD_GLOBAL|...); and later dlopen("libbar.so", ...) which uses foo, that would work -- libbar.so will be able to use foo from libfoo.so without doing any dlsym calls.

Is there symbol conflict when loading two shared libraries with a same symbol

My question is, when app loads liba.so and libb.so by dlopen(), will there be any symbol conflict for the two Hello() implementations?

There is none. These are addresses returned, and both dynamically loaded libraries will live in a separate address space.

Even the dlsym function cannot be confused since you pass the handle returned by the dlopen function, so it would not by any mean become ambiguous.

(This would not even be an issue with overloading within the same library, respectively)

Is it possible to link a shared library (from another shared library), without making its symbols globally visible?

In case you are ok with changing names of symbols from libC.so.2 you can use Implib.so's renaming functionality. E.g. to change all libC.so.2 symbols to have MYPREFIX_ prefix:

$ cat mycallback.c
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

#ifdef __cplusplus
extern "C"
#endif
void *mycallback() {
  void *h = dlmopen(LM_ID_NEWLM, "libxyz.so", RTLD_LAZY | RTLD_DEEPBIND);
  if (h)
    return h;
  fprintf(stderr, "dlmopen failed: %s\n", dlerror());
  exit(1);
}
$ implib-gen.py --dlopen-callback=mycallback --symbol_prefix=MYPREFIX_ libC.so.2
$ ... # Link your app with libC.so.2.tramp.S, libC.so.2.init.c and mycallback.c, keep libC.so.1 unchanged

Function names in libC.so.2's header will need to be updated as well (often that's a simple s/// in vim).

Implib.so works by generating a bunch of wrappers for each symbol in problematic library (in this case libC.so.2) and forwarding calls to their actual implementation internally (via dlsym).

Referencing global symbols from shared library loaded with dlopen

You have to add the -rdynamic option when linking test:

gcc -o test main.c -ldl -rdynamic

From here:

-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

---

Related Topics