背景

OpenHarmony中，三方库的使用有两种方式：

一、固件集成

三方库经由OpenHarmony构建框架编译出的动态库或静态库，打包到rom中

二、应用集成

三方库经由IDE（通过IDE中的cmake）编译出的动态库或静态库，打包到hap包中

有时候我们想直接使用三方库，省略编译构建这个过程，直接将固件集成方式构建出来的二进制动态库在IDE上面使用。在使用过程中我们会发现，有时候编译工程，在工程链接三方库的阶段出现找不到符号导致编译失败的问题。

问题分析

问题现象

使用固件集成方式构建出来的动态库，直接在IDE上编译链接时，出现如下图现象

如图所示，提示ld.lld: error: undefined symbol: print(std::__n1::basic_string<char, std::__n1::char_traits>, std::__n1::allocator >)

分析动态库

由上面现象中提示链接时没有找到对应函数符号，我们分析一下动态库的符号表，查看是否存在该符号

通过查看动态库的符号表，我们可以发现存在该函数符号，但是参数中的变量命名空间有所区别，IDE中是std::__n1，而固件集成方式编译出来的动态库是std::__h，从这里看出可能是基础库libc++.so或libc.so有所差异

分析基础库差异

我们对比一下IDE的SDK和OpenHarmony的sdk中的基础库（libc++.so/libc.so）

首先对比libc++.so的符号表（左：IDE中的libc++，右：OpenHarmony中的libc++）

从上图可以看出函数的命名空间被隔离开了，并且部分函数不一致，是新增的

对比libc.so的符号表（左：IDE中的libc，右：OpenHarmony中的libc）

从上图可以看出部分函数有新增

总结

通过以上分析出来的现象，和工具链相关的负责人沟通，命名空间隔离是由工具链这边自己进行隔离的，因为系统侧和ndk侧两边发布版本的节奏不一致，版本不同，如果强行统一会导致api不兼容，数据结构差异等问题。所以固件集成方式构建的库和应用集成构建的库不可以混用。

为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05

《鸿蒙开发学习手册》：

如何快速入门：https://qr21.cn/FV7h05

1. 基本概念
2. 构建第一个ArkTS应用
3. ……

开发基础知识：https://qr21.cn/FV7h05

1. 应用基础知识
2. 配置文件
3. 应用数据管理
4. 应用安全管理
5. 应用隐私保护
6. 三方应用调用管控机制
7. 资源分类与访问
8. 学习ArkTS语言
9. ……

基于ArkTS 开发：https://qr21.cn/FV7h05

1. Ability开发
2. UI开发
3. 公共事件与通知
4. 窗口管理
5. 媒体
6. 安全
7. 网络与链接
8. 电话服务
9. 数据管理
10. 后台任务(Background Task)管理
11. 设备管理
12. 设备使用信息统计
13. DFX
14. 国际化开发
15. 折叠屏系列
16. ……

鸿蒙开发面试真题（含参考答案）：https://qr18.cn/F781PH

鸿蒙开发面试大盘集篇（共计319页）：https://qr18.cn/F781PH

1.项目开发必备面试题
2.性能优化方向
3.架构方向
4.鸿蒙开发系统底层方向
5.鸿蒙音视频开发方向
6.鸿蒙车载开发方向
7.鸿蒙南向开发方向