dlopen documentation oversight

The documentation for dlopen, and the documentation talking about
creating shared libraries, fails to mention that you need to link your
executable program with -Wl,-E in order to have the symbols in the
executable made globally available to any demand-loaded shared
libraries.

Andrew

Andrew Thomas <Andrew@cogent.ca> wrote:

The documentation for dlopen, and the documentation talking about
creating shared libraries, fails to mention that you need to link your
executable program with -Wl,-E in order to have the symbols in the
executable made globally available to any demand-loaded shared
libraries.

Thanks, I’ll mention this to the docs people.


cburgess@qnx.com

cburgess@qnx.com wrote:

Andrew Thomas <> Andrew@cogent.ca> > wrote:
The documentation for dlopen, and the documentation talking about
creating shared libraries, fails to mention that you need to link your
executable program with -Wl,-E in order to have the symbols in the
executable made globally available to any demand-loaded shared
libraries.

Thanks, I’ll mention this to the docs people.


cburgess@qnx.com

The following has been added to the dlopen() description:

  • Donna


    Symbol Resolution

When resolving the symbols in the shared object,
the runtime linker searches for them in the dynamic symbol table
using the following order:

By default:
1.main executable
2.the shared object being loaded
3.all other loaded shared objects that were loaded
with the RTLD_GLOBAL flag.

When -Bsymbolic is specified:
1.the shared object being loaded
2.main executable
3.all other loaded shared objects that were loaded
with the RTLD_GLOBAL flag.

For executables, the dynamic symbol table typically contains only those symbols
that are known to be needed by any shared libraries. This is determined by the
linker when the executable is linked against a shared library.

Since you don’t link your executable against a shared object that you load with dlopen(),
the linker can’t determine which executable symbols need to be made available to the
shared object. If your shared object needs to resolve symbols in the exectuable,
then you may force the linker to make all of the symbols in the executable available
for dynamic linking by specifying the -E linker option. For example:

qcc -Vgcc_ntox86 -Wc,-E -o main main.o

Shared objects always place all their symbols in dynamic symbol tables,
so this option isn’t needed when linking a shared object.