C++跨标准版本兼容性检测实例
在本章节开始前,简单介绍下目前玲珑生态提供的runtime状态.目前提供了20、23版本的Runtime以及Foundation用于构建及运行程序,部分场景下需要维护者根据实际情况或报错信息选择合适的Runtime以及Foundation.
在选择适合当前项目的Runtime以及Foundation前,你需要特别关注不同版本之间的重要差异,以便能更好地选择合适的版本,可参考以下表格:
Runtime/Foundation:
Version | Base | GCC |
---|---|---|
20.0.0 | deepin V20 | 8.3.0 |
23.0.0 | deepin V23 | 13.2.0 |
注:玲珑中Runtime/Foundation实际版本号由四位小数展示,第一位上的数值代表版本号,即不同系统基线,第四位版本号支持自动匹配,当不存在第四位版本号时,构建 程序将自动使用该系统基线Runtime的最新版本
对于Runtime以及Foundation版本选择的建议,如果是从deb包转换我们一般会建议使用与构建环境相仿的Runtime版本.比如我在deepin V20平台上使用GCC 8.3构建了一款开源Qt应用并封装为deb安装包,现需要将该deb包转换为玲珑应用,那么我们在构建导出时应该选择环境接近的Runtime 20.0.0版本.
但对于日常应用生态维护而言,你维护的应用安装包并不总是由你亲自编译构建的,你并不知悉该二进制文件是基于何GCC版本进行编译,因此需要使用最新版本进行构建测试,如果构建失败则可以通过报错信息进行分析,确认合适的Runtime版本
本案例采用了商业闭源软件”QQ音乐Linux版”,在根据第一章节通过脚本将deb包转换为玲珑安装文件”layer”并安装到系统中后,通过启动器打开发现没有任何响应.这个节点可以参考”adep模块”阶段所使用的调试方法来确认是否存在错误信息导致无法成功启动.
查看调试信息,可以看到一个比较明显的错误,即”cxx11″的报错.如果我们对GCC不同版本默认使用的C++标准有所了解的话,结合前面对Runtime/Foundation内置GCC版本的介绍,可以定位到该报错和GCC所使用的C++11标准构建有关。
可以看到GCC8.3默认C++标准为c++14,GCC13.2则为c++17。GCC8.3的默认显然更接近报错的c++11。再返回查看本项目的yaml配置文件,发现使用了GCC 的23 Runtime,此处我们考虑更换为20 Runtime.修改版本号、保存配置文件后重新构建,安装后可以正常运行。因此足以看出我们这里的排查方向是正确的
发表回复