Porting a Third-Party C/C++ Library
If no appropriate third-party JS/TS library is available, you can click here to obtain the verified third-party C/C++ libraries. Generally, third-party C/C++ libraries have higher running efficiency than JS/TS third-party components. You must build the third-party C/C++ libraries in the OpenHarmony compilation environment beforehand, and encapsulate Node-APIs or use @ohos/aki to provide JS APIs for applications. The following describes how to efficiently port a third-party C/C++ library to OpenHarmony.
C/C++ adaptation issues and solutions
The preceding figure shows the process, key blocking points, and solutions for porting a third-party C/C++ library. The following describes how to efficiently port this library to OpenHarmony.
Step 1: Runtime Dependency Analysis
You can use the c/c++ risk identification tool to scan whether a third-party library depends on APIs provided by NDK, OpenGL, or Bionic C library. This tool can quickly identify risks of a third-party C/C++ library.
If the library depends on incompatible APIs, it cannot be ported. In this case, you should consider porting alternative libraries. Even if the library does not depend on the mentioned APIs, verification is still necessary to ensure compatibility. Note that you should analyze the source code of the dependency library as well.
Step 2: Compilation and Build
DevEco Studio is used for OpenHarmony application compilation and development. Currently, this IDE supports compilation with CMake but the open-source third-party C/C++ libraries can be compiled using CMake, configure script, or other tools. If a native library compiled by CMake cannot be built in DevEco Studio, analyze the issue and modify the CMakeLists.txt file of the native library. For a third-party library that is not compiled with CMake, you also need to analyze its compilation mode, write the CMakeLists.txt file, and change the compilation mode to CMake compilation. These processes are time-consuming, especially for some large third-party C/C++ libraries.
To solve these issues, we have developed lycium based on Linux, which is a tool for cross-compiling third-party libraries using the compilation script of the native library. This tool can help you quickly compile and build OpenHarmony-compatible third-party C/C++ libraries on Linux.
When you use lycium to compile the open-source library, the usr directory is generated in the lycium directory, and contains the header files and built 32-bit and 64-bit third-party libraries. Pay attention to the following: ● Compile the dependent library (if any) together with the third-party library. Otherwise, the framework cannot compile and build the libraries. ● There are two third-party libraries in the installation directory. armeabi-v7a corresponds to the 32-bit library, and arm64-v8a corresponds to the 64-bit library. Then, you can test and verify the third-party libraries.
Step 3: Testing and Verification
There are various test frameworks in the industry, which cannot be unified. Therefore, to ensure the function integrity of the native library, we verify the sample library based on the native one. We have integrated a set of CI environment to perform operations, such as executing the make test command, in the OpenHarmony environment. After this environment is configured, we can run the sample library in the OpenHarmony environment.
Step 4: Usage
After the verification is successful, the third-party library can be used. Copy the binary files of the third-party library to the \\entry\libs\armxx\ directory of the corresponding project, and copy the header files to the \\entry\src\main\cpp directory.
You can refer to the integration of the curl library into an HAP application to understand the use of third-party libraries.
- Copy the dynamic library to the
\\entry\libs\${OHOS_ARCH}\directory so that it can be integrated into the HAP, which indicates you need to copy the corresponding .so file to the directory of the CPU architecture.
- Add the thirdparty directory to the cpp directory, and copy the library generated after compilation to the thirdparty directory.
-
Add the following statements to the CMakeLists.txt file in the cpp directory to add the third-party library and its header files to the project.
target_link_libraries(entry PRIVATE ${CMAKE_SOURCE_DIR}/../../../libs/${OHOS_ARCH}/libcurl.so) # Add the third-party library to the project. target_include_directories(entry PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/curl/${OHOS_ARCH}/include) # Add the header file of the third-party library to the project.
Then, you can use the third-party library.
Step 5: JS/TS API Development
Provide Node-APIs or use @ohos/aki to provide JS/TS APIs for applications.
Step 6: Standardization of the Source Code Directory
Standardize the source code directory structure by referring to the directory of the commons-compress third-party library, import the source code or binary files of the third-party library to the cpp directory, and import the JS APIs to the ets directory.
/commons-compress # Source code of the third-party library
├── src # Framework code
│ └── main
│ └── cpp
│ ├── zstd # zstd C source code
│ └── zstd.cpp # Zstandard Node-API
│ └── ets
│ └── components
│ └── archivers
│ ├── ar # ar source code
│ ├── cpio # cpio source code
│ ├── dump # dump source code
│ ├── lzma # LZMA source code
│ ├── tar # tar source code
│ └── zip # zip source code
│ └── compressors
│ ├── brotli # Brotli source code
│ ├── bzip2 # bzip2 source code
│ ├── lz77support # LZ77 source code
│ ├── lzw # LZW source code
│ ├── snappy # Snappy source code
│ ├── xz # XZ source code
│ └── z # Z source code
│ ├── deflate # Deflate source code
│ ├── gzip # gzip source code
│ ├── lz4 # LZ4 source code
│ ├── util # Utility source code
│ └── zstd # Zstandard source code