Dependency Ordering

When dynamic executables and shared objects have dependencies on the same common shared objects, the order in which the objects are processed can become less predictable.

For example, assume a shared object developer generates libfoo.so.1 with the following dependencies.

$ ldd libfoo.so.1
        libA.so.1 =>     ./libA.so.1
        libB.so.1 =>     ./libB.so.1
        libC.so.1 =>     ./libC.so.1

If you create a dynamic executable prog, using this shared object, and define an explicit dependency on libC.so.1, the resulting shared object order will be as follows.

$ cc -o prog main.c -R. -L. -lC -lfoo
$ ldd prog
        libC.so.1 =>     ./libC.so.1
        libfoo.so.1 =>   ./libfoo.so.1
        libA.so.1 =>     ./libA.so.1
        libB.so.1 =>     ./libB.so.1

Any requirement on the order of processing the shared object libfoo.so.1 dependencies would be compromised by the construction of the dynamic executable prog.

Developers who place special emphasis on symbol interposition and .init section processing should be aware of this potential change in shared object processing order.