Object Hierarchies
If an initial object is obtained from a
dlopen
(3C), and uses
dlopen
() to open a secondary
object, both objects are assigned to a unique group.
This situation can prevent either object from
locating symbols from the other.
In some implementations the initial object has to export symbols for the relocation of the secondary object. This requirement can be satisfied by one of two mechanisms.
-
Making the initial object an explicit dependency of the second object.
-
Use the
RTLD_PARENT
mode flag todlopen
(3C) the secondary object.
If the initial object is an explicit dependency of the secondary object, the initial object is assigned to the secondary objects' group. The initial object is therefore able to provide symbols for the secondary objects' relocation.
If many objects can use
dlopen
(3C) to open the secondary
object, and each of these initial objects must
export the same symbols to satisfy the secondary
objects' relocation, then the secondary object
cannot be assigned an explicit dependency. In this
case, the
dlopen
(3C) mode of the secondary
object can be augmented with the
RTLD_PARENT
flag. This flag
causes the propagation of the secondary objects'
group to the initial object in the same manner as an
explicit dependency would do.
There is one small difference between
these two techniques. If you specify an explicit
dependency, the dependency itself becomes part of
the secondary objects'
dlopen
(3C) dependency tree, and thus
becomes available for symbol lookup with
dlsym
(3C). If you obtain the
secondary object with
RTLD_PARENT
, the initial object
does not become available for symbol lookup with
dlsym
(3C).
When a secondary object is obtained by
dlopen
(3C) from an initial object
with global symbol visibility, the
RTLD_PARENT
mode is both
redundant and harmless. This case commonly occurs
when
dlopen
(3C) is called from an
application or from one of the dependencies of the
application.