1# C/C++ Mechanisms 2 3OpenHarmony NDK provides industry standard libraries [libc](../reference/native-lib/musl.md) and [libc++](../reference/native-lib/cpp.md). This topic describes the mechanisms of these libraries in OpenHarmony. Understanding these mechanisms helps you avoid pitfalls during NDK development. 4 5## C++ Compatibility 6 7In OpenHarmony, both the system library and application native library use C++ standard library (see [libc++](../reference/native-lib/cpp.md)). However, the C++ standard library used by the system library is updated with the image version, and the C++ standard library used by the app native library is updated with the SDK used for compilation. Since both the C++ standard libraries have multiple major versions, the different update approach may cause ABI compatibility issues. To solve this problem, OpenHarmony differentiates the two C++ standard libraries as follows: 8 9- System library: uses **libc++.so**, which is released with the system image. 10- Application native library: uses **libc++_shared.so**, which is released with the application. 11 12The two libraries use different C++ namespaces. **libc++.so** uses **__h** as the namespace of C++ symbols, and **libc++_shared.so** uses **__n1** as the namespace of C++ symbols. 13 14>**NOTE**<br>The system and applications must use their own C++ standard library. Currently, native APIs are C interfaces only, which can isolate the C++ running environments of them. When a Harmony Archive (HAR) is used to build an application, if the **libc++_shared.so** version in the HAR is different from the **libc++_shared.so** version of the application, only one version will be installed in the application, which may cause compatibility issues. To solve the problem, you can use the same SDK version to update the HAR. 15 16>**Known C++ compatibility issue**: If "symbol not found, s=\_\_emutls_get_address" is reported when an application is started or **dlopen** is called, update the SDK version of the application or HAR to 4.0 or later. This symbol is not provided by **libc++\_shared.so** in the SDK of API version 9 or earlier, and is available in **libc++\_shared.so** from the SDK of API version 11. 17 18## musl libc Dynamic Linker 19 20### Linker Namespace 21Different from the namespace in C++, a linker namespace (also referred to as ns) is a mechanism provided by the dynamic linker to isolate shared libraries within different namespaces. For example, the system native library can load the native library in the system directories, such as **/system/lib64** or **/vendor/lib64**; a common application can load only the common application native library and NDK library, but cannot directly load the system native library. 22 23The dynamic linker must be associated with a specific namespace no matter whether it loads the shared library specified by **DT_NEEDED** in compilation or calls **dlopen** to load a shared library. 24 25OpenHarmony has the following types of linker namespaces: 26 27- Default ns: default namespace created for locating the .so files in **/system/lib{abi}** and **/vendor/lib{abi}** when the dynamic linker stats. 28 29- NDK ns: default namespace created for exposing the NDK interfaces in .so files in **/system/lib{abi}/ndk** when the dynamic linker stats. 30 31- App ns: namespace created when an application is started. It directs to the application installation path (sandbox path), that is, the .so file used to load the application. 32 33The namespace mechanism restricts the invocation between the application native library and the system native library, as shown in the following figure. 34 351. The default ns and NDK ns can access all .so files of each other, but cannot access the .so files of the app ns. 362. The app ns can access all .so files of the NDK ns, but cannot access the .so files of the default ns. 37 38 39 40### rpath 41Run-time path (rpath) is a mechanism for specifying the runtime search path of a shared library. This mechanism allows a runtime search path to be embedded in an executable file or shared library. The dynamic linker uses this path to find required libraries. 42 43The namespace mechanism allows an application to load only the native libraries in its installation directory (for example, **libs/arm64** on the ARM64 platform). If an application needs to load multiple native libraries, multiple loading paths need to be created to facilitate management. However, the native library in the newly created directory cannot be loaded. In this case, you can use the rpath mechanism to specify the search path during compilation. 44 45For example, **libhello.so** in the application installation directory **lib/arm64** depends on **libworld.so** in the newly created directory **lib/arm64/module**. Set **rpath** in the **CMakeList.txt** file of the application and compile the file, and run **readelf** to view the rpath of **libhello.so**. As shown in the following figure, **$ORIGIN** indicates the path of **libhello.so**. The application can load **libworld.so** in the **module** directory during running. 46``` 47SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 48SET(CMAKE_INSTALL_RPATH "\${ORIGIN}/module") 49``` 50 51 52### dlclose 53You can use **dlclose** to uninstall a dynamic library. 54 55### symbol-version 56symbol-version is a symbol retrieval mechanism provided by libc for symbol relocation in dynamic linking. It supports relocation of the symbols of different versions and helps solve the problem of duplicate symbols. For details, see <a href="https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html">LD Version Scripts (GNU Gnulib)</a>. 57 58### Fortified Check of the FD in select() 59If the file descriptor (**fd**) passed in **FD_SET** or **FD_CLR** is not within the value range [0, 1024), abort crash will be triggered. 60 61If the **fd** value passed in **FD_ISSET** is not within the value range [0, 1024), **false** will be returned. 62 63### Globalization 64Since API version 12, **locale** in **newlocale()** and **setlocale()** can be set to any of the following values: **C**, **C.UTF-8**, **en_US**, **en_US.UTF-8**, **zh_CN**, and **zh_CN.UTF-8**. 65 66**strtod_l**, **wcstod_l**, and **localeconv** support the **locale** values **zh_CN** and **zh_CN.UTF-8**. 67 68Note that **strtod_l()** and **wcstod_l()** do not support conversion of hexadecimal numbers and floating-point numbers. 69 70### fdsan 71File descriptor sanitizer ([fdsan](./fdsan.md)) helps detect the user-after-close and double-close issues of FDs. 72
