The symbolic conflict between the dynamic link library so and the Linux __linux

To write a dynamic link library program under Linux, you need to be aware of the symbolic conflicts between DLLs.

When our link library needs to be provided to many Parties for integrated use, we need to face a complex integration environment, one of the major problems is the symbolic conflict with the third party integration environment.

Some of these conflicts are not solved by strictly controlling the namespace, for example, when we use some open source libraries, we do not know if there is a Third-party integration environment, and even if there is a version match, we do not want to make too many demands on the third party integration environment, which increases the integration cost. In this case, we will link these open source libraries statically to our dynamic link library, providing only one so file. But this is not enough to avoid symbolic conflicts.

The dynamic link mechanism under Linux allows multiple so libraries to define the same symbols without a symbolic duplicate definition error at build time. This conflict also does not have error warning messages at run time, and the run-time link process typically uses the earliest version of the duplicate-defined symbol, unless explicitly used with the DLSYM system API.

Therefore, it is not certain that it will bind to that version of the symbol at run time. This conflict is bidirectional, our link library may be using the symbolic version of the third party integration environment incorrectly, on the other hand, the third party environment may incorrectly bind the symbolic version of the Open Source Library in our link library.

The way to resolve the conflict is to hide the symbols in the open source library that we use. The program construction is divided into two steps of compiling and linking, and there are methods of hiding the symbol in both of these steps.

In the compile phase, you can specify the Visible property __attribute__ (Visibility ("hidden")) of the symbol, for example:

void func () __attribute__ (Visibility ("hidden"));

However, it is not possible to add visible attributes to all the symbols, so GCC provides-fvisibility=hidden compilation flag that can be set to hide all symbols. At this point, you need to explicitly see the attributes for the symbols that should be exported, such as:

void Export_func () __attribute__ (visibility ("default"));

In the link phase, the symbols can be divided into local and global categories through the version script file. The symbol to export is attributed to the global class. If we create the file Mylib.ver, the content is:

{
        global:
                export_func;

        Local: *;
};

Specify flag when linking: "-wl,--version-script=mylib.ver".