gettext是一个用于软件国际化i18n和本地化l10n的工具集其核心作用是帮助程序根据用户的语言环境动态地将界面文本翻译成多种语言从而支持多语言用户。文章目录二、gettext 的主要功能和用途2.1 消息翻译与编目管理2.2 支持多语种界面2.3 简化代码中的翻译处理2.4 分离代码与文本内容2.5 兼容性与灵活性2.5 典型工作流程以软件开发为例三、如何在鸿蒙PC命令行工具中移植三方库gettext3.1 编译环境准备3.2 下载并配置ohos-sdk版本OpenHarmony_6.1.0.283.3 配置环境变量3.4 编译三方库gettext命令集3.5 确认编译产物3.6 鸿蒙PC端验证四、错误处理4.1 错误1Relocations in generic ELF (EM:183) error adding symbols:file in wrong format4.2 错误2checking host system type... Invalid configuration aarch64-linux-ohos: OS ohos not recognized4.3 错误3Error loading shared library libintl.so.8: No such file or directoryneeded by ./hello_getttext_other五、总结欢迎加入开源鸿蒙PC社区https://harmonypc.csdn.net/## 一、什么是gettextgettext的主要作用是为软件提供国际化i18n和本地化l10n支持使程序能够以用户选择的语言显示界面文本、提示信息等。具体来说它的核心功能包括文本翻译程序中的固定文本如按钮标签、错误提示、菜单项被标记为可翻译的字符串。在运行时gettext会根据系统语言设置从对应的“消息目录”.mo 文件中查找并返回翻译后的文本。基于消息目录它不提供自动翻译服务而是依赖开发者提供翻译文件.po 文件经编译为 .mo 文件。这些文件包含原始文本msgid与对应语言的翻译msgstr的映射关系。支持多种语言环境通过读取环境变量如LANG、LC_ALL和系统 locale 设置gettext能自动适配用户的语言偏好。广泛应用于开源软件它是 GNU 项目和许多 Linux 应用程序的标准本地化方案被用于翻译命令行工具、桌面应用等。二、gettext 的主要功能和用途2.1 消息翻译与编目管理gettext 提供了一套与 GNU gettext 兼容的纯 Python 实现用于从源代码中提取需要翻译的字符串并构建翻译消息目录.po/.mo 文件从而在运行时根据用户的语言环境动态加载对应的翻译。2.2 支持多语种界面通过 gettext开发者可以为应用程序创建不同语言版本的消息编目使程序能够以适合用户的语言显示消息实现国际化界面。2.3 简化代码中的翻译处理在代码中通常使用 _() 函数单下划线包装需要翻译的字符串而不是直接使用硬编码的文本。这样gettext 可以在运行时替换为对应语言的翻译内容。2.4 分离代码与文本内容gettext 并不自动翻译文本而是帮助开发者提取、组织和访问程序中使用的文本消息将翻译工作与代码逻辑分离便于维护和协作。2.5 兼容性与灵活性gettext 模块提供两套 API高层 API类似于 GNU gettext适用于单语言场景依赖用户的语言环境设置。基于类的 API允许在模块级别进行本地化支持运行时动态切换语言。2.5 典型工作流程以软件开发为例标记源代码在代码中用 _(“文本”) 标记需翻译的字符串。提取字符串使用 xgettext 工具生成 POT模板文件。翻译字符串将 POT 转换为 PO 文件由翻译人员填写译文。- 编译翻译使用 msgfmt 将 PO 文件编译为二进制 MO 文件。部署翻译将 MO 文件放在指定位置供程序加载。三、如何在鸿蒙PC命令行工具中移植三方库gettext3.1 编译环境准备在鸿蒙PC命令行工具中移植使用的是交叉编译的方式交叉编译是指在A架构如x86_64 Linux编译出能在B架构如鸿蒙PC运行的程序这样可以达到命令跨平台运行的目的。本人使用的是vagrant ubuntu 22.04的镜像包进行的测试,在x86_64的Linux主机Ubuntu 24.04上编译出能在aarch64架构HarmonyOS系统的鸿蒙PC上运行的程序。学习教程可以看看Ubuntu如何搭建OpenHarmony_6.1.0.28的lycium_plusplus及鸿蒙 PC 环境设计的 C/C 编译框架 这个文章讲的还是比较详细的。3.2 下载并配置ohos-sdk版本OpenHarmony_6.1.0.28直接使用wget将这个包下载下来我们可以看到这个包的大小有2.33Gwget https://cidownload.openharmony.cn/version/Daily_Version/OpenHarmony_6.1.0.28/20260120_120146/version-Daily_Version-OpenHarmony_6.1.0.28-20260120_120146-ohos-sdk-full.tar.gz使用tar来解压这个gz压缩包tar xf version-Daily_Version-OpenHarmony_6.1.0.28-20260120_120146-ohos-sdk-full.tar.gz接下来我们进入linux目录中我们解压native模块unzip-q native-linux-x64-6.1.0.28-Beta1.zip同时再次解压toolchains模块unzip-q toolchains-linux-x64-6.0.0.46-Beta1.zip3.3 配置环境变量SDK解压完成之后这里我们设置一下全局的环境变量配置交叉编译必备的环境变量可以根据自己的exportOHOS_SDK~/harmonypc/linux echo $OHOS_SDK# 下面的都是根据上面的环境变量来动态配置的不需要改动exportPATH${OHOS_SDK}/native/llvm/bin:${OHOS_SDK}/native/build-tools/cmake/bin:$PATHexportAS${OHOS_SDK}/native/llvm/bin/llvm-asexportCC${OHOS_SDK}/native/llvm/bin/clang --targetaarch64-linux-ohosexportCXX${OHOS_SDK}/native/llvm/bin/clang --targetaarch64-linux-ohosexportLD${OHOS_SDK}/native/llvm/bin/ld.lldexportSTRIP${OHOS_SDK}/native/llvm/bin/llvm-stripexportRANLIB${OHOS_SDK}/native/llvm/bin/llvm-ranlibexportOBJDUMP${OHOS_SDK}/native/llvm/bin/llvm-objdumpexportOBJCOPY${OHOS_SDK}/native/llvm/bin/llvm-objcopyexportNM${OHOS_SDK}/native/llvm/bin/llvm-nmexportAR${OHOS_SDK}/native/llvm/bin/llvm-arexportCFLAGS-fPIC -D__MUSL__1exportCXXFLAGS-fPIC -D__MUSL__1上面在设置完全局环境变量后我们再执行$CC -v命令可以查询到clang的版本号就说明设置成功了,到此为止编译环境就全部准备就绪接下来就可以进行编译移植了。3.4 编译三方库gettext命令集提供的链接https://ftp.gnu.org/gnu/gettext/gettext-0.26.tar.gz是gettext工具包 0.26 版本的源代码压缩包。下载并编译此包即可获得gettext命令行工具如xgettext、msgfmt、msgmerge这些工具用于从源代码中提取可翻译字符串、管理翻译文件并生成最终的 .mo 文件是实现软件多语言支持的基础设施。源码的原始仓库维护在github上我们直接使用wget下载下来wget https://ftp.gnu.org/gnu/gettext/gettext-0.26.tar.gz tar xf gettext-0.26.tar.gz cd gettext-0.26配置编译规则通过configure脚本指定目标架构、安装路径、依赖等核心参数说明完整配置命令CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_targetaarch64-unknown-linux-musl目标架构对应鸿蒙PC的aarch64-linux-ohos–prefix指定安装路径建议设为源码目录下的target方便后续引用使用make命令进行编译(多线程编译可根据CPU核心数调整-j后的数字加快编译速度)make使用make install命令安装到指定路径–prefix指定的target目录这里是当前源码目录下的geettext_target目录make install1.configure是GNU Autotools生成的配置脚本核心作用是检测环境、适配平台、生成Makefile新手只需掌握“配置→编译→安装”核心三步2.鸿蒙PC交叉编译的核心是通过–hostaarch64-linux-ohos指定目标架构并提前配置鸿蒙PC SDK的交叉编译器环境变量3.鸿蒙PC编译需确保编译器、依赖库均为适配鸿蒙PC的aarch64版本避免混用x86架构的工具或依赖。3.5 确认编译产物安装完成后进入target目录会看到以下核心产物适配aarch64-linux-ohos架构lib/库文件目录包含libintl.so.8核心文件。bin/工具目录包含鸿蒙PC版可执行文件用于验证库可用性如xgettext、msgfmt、msgmerge等这里我们可以看到gettext相关的工具。那么我们可以手写一个C的程序来验证一下库是否可用#includestdio.h#includelocale.h#includelibintl.hintmain(){setlocale(LC_ALL,);bindtextdomain(hello,./locales);textdomain(hello);printf(gettext(Hello, world!\n));return0;}以上代码的作用是这段 C 程序使用 GNU gettext 的国际化框架libintl为字符串“Hello, world!\n”提供按系统语言自动切换的翻译并输出到标准输出。etlocale(LC_ALL, “”)按当前环境变量LANG、LC_ALL、LANGUAGE 等设置程序的区域与编码。空字符串表示“从环境继承”如 zh_CN.UTF-8、en_US.UTF-8。bindtextdomain(“hello”, “./locales”)为消息域 hello 指定翻译文件的根目录。运行时会在 ./locales/textdomain(“hello”)设置当前默认消息域为 hello后续 gettext(…) 就在这个域下查找。gettext(“Hello, world!\n”)以“Hello, world!\n”为消息 ID在 hello 域对应的 .mo 文件中查翻译找不到时返回原文。printf(…)将翻译结果打印到标准输出最后 return 0 正常退出。接下来我们使用鸿蒙PC的clang进行编译将上面写的C程序编译成可执行文件生成中文翻译文件 locales/zh_CN/LC_MESSAGESmkdir-p locales/zh_CN/LC_MESSAGES生成中文翻译文件 locales/zh_CN/LC_MESSAGES/hello.pomsgidmsgstrContent-Type: text/plain; charsetUTF-8\nLanguage: zh_CN\nmsgidHello, world!\nmsgstr你好世界\n编译 .mo 并准备目录结构msgfmt-o locales/zh_CN/LC_MESSAGES/hello.mo locales/zh_CN/LC_MESSAGES/hello.po接下来我们使用clang进行编译将上面写的C程序编译成可执行文件/root/harmonypc/linux/native/llvm/bin/clang--targetaarch64-linux-ohos\-I/root/test/gettext-0.26/geettext_target/include \/root/test/main.c \-L/root/test/gettext-0.26/geettext_target/lib \-lintl-o/root/test/hello_getttext这里最后打包的文件为hello_getttext将hello_getttext拷贝到鸿蒙PC的/root目录下。注意在lib目录下面有一个libintl.so.8文件这个文件是gettext库的动态链接库我们需要将这个文件拷贝到鸿蒙PC的/root目录下。3.6 鸿蒙PC端验证所有文件拷贝到鸿蒙PC之后启动终端执行binary-sign-tool命令分别对hello_getttext进行自签名。先需要进行签名部署在鸿蒙 PC 上部署的程序和库文件完成后需要进行 签名 操作保证安全性与系统兼容性binary-sign-tool sign-inFile \xxxx\hello_getttext-outFile \xxxx\hello_getttext-selfSign1如果出现 “Permission denied” 等错误需要检查当前用户是否有足够的权限执行这些操作或者尝试使用sudo来提升权限我这里使用chmod 755 命令来修改文件权限。接下来执行hello_getttext程序至此鸿蒙PC版的hello_getttext编译移植完成。四、错误处理4.1 错误1Relocations in generic ELF (EM:183) error adding symbols:file in wrong format在编译鸿蒙PC版的geettext时configure已经顺利通过但是执行make命令编译时最后链接阶段遇到如下报错从日志看编译器使用的ohos sdk的clang但是最终链接so时链接器没有使用ohos sdk的lld而是用了系统的ld即使我们定义了LD环境变量也不起作用就导致了最终的链接失败。在CFLAGS里指定了–targetaarch64-linux-ohos架构但是libtool并没有去使用它导致平台架构判断失败使用了错误的链接器。要解决这个问题需要在执行configure命令时给CC环境变量强制追加一个–targetaarch64-linux-ohos参考命令如下所示我们将预先定义好的CFLAGS环境变量追加给CC环境变量即可CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_target重新执行./configure之后重新运行make命令就可以顺利编译通过了。4.2 错误2checking host system type… Invalid configurationaarch64-linux-ohos: OSohos’ not recognizedds-c and-o together...yes checkingforstdio.h...yes checkingforstdlib.h...yes checkingforstring.h...yes checkingforinttypes.h...yes checkingforstdint.h...yes checkingforstrings.h...yes checkingforsys/stat.h...yes checkingforsys/types.h...yes checkingforunistd.h...yes checkingforwchar.h...yes checkingforminix/config.h...no checkingforvfork.h...no checking whether it is safe to define __EXTENSIONS__...yes checking whether _XOPEN_SOURCE should be defined...no checking build system type...x86_64-pc-linux-gnu checking host system type...Invalid configurationaarch64-linux-ohos: OSohos not recognizedconfigure:error:/bin/bash././config.sub aarch64-linux-ohos failed基于OHOS SDK环境对某些C/C应用进行交叉编译时需要指定–hostaarch64-linux-ohos参数以便configure能正常识别目标平台架构和编译器等信息在编译命令时遇到了一个报错在执行configure过程中调用了/bin/bash ./build-aux/config.sub aarch64-linux-ohos但是脚本不识别ohos这个配置导致configure失败更换host为aarch64-unknown-linux-musl更换–host参数重新执行configure命令CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_target4.3 错误3Error loading shared library libintl.so.8: No such file or directoryneeded by ./hello_getttext_other接下来尝试运行hello_getttext_other命令发现报错了找不到几个共享库原因是因为这几个共享库文件并不在系统查找动态库的标准路径中。解决办法是设置环境变量LD_LIBRARYA_PATH将共享库所在路径追加到环境变量LD_LIBRARYA_PATH中如下所示假设这几个共享库位于hello_getttext_other命令同一层级下那么我们可以这样设置export LD_LIBRARYA_PATH…/:$LD_LIBRARYA_PATH如下图所示exportLD_LIBRARYA_PATH../:$LD_LIBRARYA_PATH五、总结鉴于鸿蒙操作系统HarmonyOS是一种与Windows、Linux及macOS等传统操作系统不同的新型平台其软件架构和EABIEmbedded Application Binary Interface等特性均采用了全新的设计统一配置鸿蒙SDK的工具链环境变量能从根源上避免编译工具冲突保证交叉编译的一致性和可复现性本次移植的gettext库版本为0.26该版本基于musl libc构建与鸿蒙PC的底层libc完全兼容编译产物无任何依赖问题可直接在鸿蒙PC上稳定运行无崩溃、无内存泄漏。欢迎加入开源鸿蒙PC社区 。
【鸿蒙PC命令行适配】鸿蒙 PC 实战：交叉编译gettext三方库，实现中英文转换
gettext是一个用于软件国际化i18n和本地化l10n的工具集其核心作用是帮助程序根据用户的语言环境动态地将界面文本翻译成多种语言从而支持多语言用户。文章目录二、gettext 的主要功能和用途2.1 消息翻译与编目管理2.2 支持多语种界面2.3 简化代码中的翻译处理2.4 分离代码与文本内容2.5 兼容性与灵活性2.5 典型工作流程以软件开发为例三、如何在鸿蒙PC命令行工具中移植三方库gettext3.1 编译环境准备3.2 下载并配置ohos-sdk版本OpenHarmony_6.1.0.283.3 配置环境变量3.4 编译三方库gettext命令集3.5 确认编译产物3.6 鸿蒙PC端验证四、错误处理4.1 错误1Relocations in generic ELF (EM:183) error adding symbols:file in wrong format4.2 错误2checking host system type... Invalid configuration aarch64-linux-ohos: OS ohos not recognized4.3 错误3Error loading shared library libintl.so.8: No such file or directoryneeded by ./hello_getttext_other五、总结欢迎加入开源鸿蒙PC社区https://harmonypc.csdn.net/## 一、什么是gettextgettext的主要作用是为软件提供国际化i18n和本地化l10n支持使程序能够以用户选择的语言显示界面文本、提示信息等。具体来说它的核心功能包括文本翻译程序中的固定文本如按钮标签、错误提示、菜单项被标记为可翻译的字符串。在运行时gettext会根据系统语言设置从对应的“消息目录”.mo 文件中查找并返回翻译后的文本。基于消息目录它不提供自动翻译服务而是依赖开发者提供翻译文件.po 文件经编译为 .mo 文件。这些文件包含原始文本msgid与对应语言的翻译msgstr的映射关系。支持多种语言环境通过读取环境变量如LANG、LC_ALL和系统 locale 设置gettext能自动适配用户的语言偏好。广泛应用于开源软件它是 GNU 项目和许多 Linux 应用程序的标准本地化方案被用于翻译命令行工具、桌面应用等。二、gettext 的主要功能和用途2.1 消息翻译与编目管理gettext 提供了一套与 GNU gettext 兼容的纯 Python 实现用于从源代码中提取需要翻译的字符串并构建翻译消息目录.po/.mo 文件从而在运行时根据用户的语言环境动态加载对应的翻译。2.2 支持多语种界面通过 gettext开发者可以为应用程序创建不同语言版本的消息编目使程序能够以适合用户的语言显示消息实现国际化界面。2.3 简化代码中的翻译处理在代码中通常使用 _() 函数单下划线包装需要翻译的字符串而不是直接使用硬编码的文本。这样gettext 可以在运行时替换为对应语言的翻译内容。2.4 分离代码与文本内容gettext 并不自动翻译文本而是帮助开发者提取、组织和访问程序中使用的文本消息将翻译工作与代码逻辑分离便于维护和协作。2.5 兼容性与灵活性gettext 模块提供两套 API高层 API类似于 GNU gettext适用于单语言场景依赖用户的语言环境设置。基于类的 API允许在模块级别进行本地化支持运行时动态切换语言。2.5 典型工作流程以软件开发为例标记源代码在代码中用 _(“文本”) 标记需翻译的字符串。提取字符串使用 xgettext 工具生成 POT模板文件。翻译字符串将 POT 转换为 PO 文件由翻译人员填写译文。- 编译翻译使用 msgfmt 将 PO 文件编译为二进制 MO 文件。部署翻译将 MO 文件放在指定位置供程序加载。三、如何在鸿蒙PC命令行工具中移植三方库gettext3.1 编译环境准备在鸿蒙PC命令行工具中移植使用的是交叉编译的方式交叉编译是指在A架构如x86_64 Linux编译出能在B架构如鸿蒙PC运行的程序这样可以达到命令跨平台运行的目的。本人使用的是vagrant ubuntu 22.04的镜像包进行的测试,在x86_64的Linux主机Ubuntu 24.04上编译出能在aarch64架构HarmonyOS系统的鸿蒙PC上运行的程序。学习教程可以看看Ubuntu如何搭建OpenHarmony_6.1.0.28的lycium_plusplus及鸿蒙 PC 环境设计的 C/C 编译框架 这个文章讲的还是比较详细的。3.2 下载并配置ohos-sdk版本OpenHarmony_6.1.0.28直接使用wget将这个包下载下来我们可以看到这个包的大小有2.33Gwget https://cidownload.openharmony.cn/version/Daily_Version/OpenHarmony_6.1.0.28/20260120_120146/version-Daily_Version-OpenHarmony_6.1.0.28-20260120_120146-ohos-sdk-full.tar.gz使用tar来解压这个gz压缩包tar xf version-Daily_Version-OpenHarmony_6.1.0.28-20260120_120146-ohos-sdk-full.tar.gz接下来我们进入linux目录中我们解压native模块unzip-q native-linux-x64-6.1.0.28-Beta1.zip同时再次解压toolchains模块unzip-q toolchains-linux-x64-6.0.0.46-Beta1.zip3.3 配置环境变量SDK解压完成之后这里我们设置一下全局的环境变量配置交叉编译必备的环境变量可以根据自己的exportOHOS_SDK~/harmonypc/linux echo $OHOS_SDK# 下面的都是根据上面的环境变量来动态配置的不需要改动exportPATH${OHOS_SDK}/native/llvm/bin:${OHOS_SDK}/native/build-tools/cmake/bin:$PATHexportAS${OHOS_SDK}/native/llvm/bin/llvm-asexportCC${OHOS_SDK}/native/llvm/bin/clang --targetaarch64-linux-ohosexportCXX${OHOS_SDK}/native/llvm/bin/clang --targetaarch64-linux-ohosexportLD${OHOS_SDK}/native/llvm/bin/ld.lldexportSTRIP${OHOS_SDK}/native/llvm/bin/llvm-stripexportRANLIB${OHOS_SDK}/native/llvm/bin/llvm-ranlibexportOBJDUMP${OHOS_SDK}/native/llvm/bin/llvm-objdumpexportOBJCOPY${OHOS_SDK}/native/llvm/bin/llvm-objcopyexportNM${OHOS_SDK}/native/llvm/bin/llvm-nmexportAR${OHOS_SDK}/native/llvm/bin/llvm-arexportCFLAGS-fPIC -D__MUSL__1exportCXXFLAGS-fPIC -D__MUSL__1上面在设置完全局环境变量后我们再执行$CC -v命令可以查询到clang的版本号就说明设置成功了,到此为止编译环境就全部准备就绪接下来就可以进行编译移植了。3.4 编译三方库gettext命令集提供的链接https://ftp.gnu.org/gnu/gettext/gettext-0.26.tar.gz是gettext工具包 0.26 版本的源代码压缩包。下载并编译此包即可获得gettext命令行工具如xgettext、msgfmt、msgmerge这些工具用于从源代码中提取可翻译字符串、管理翻译文件并生成最终的 .mo 文件是实现软件多语言支持的基础设施。源码的原始仓库维护在github上我们直接使用wget下载下来wget https://ftp.gnu.org/gnu/gettext/gettext-0.26.tar.gz tar xf gettext-0.26.tar.gz cd gettext-0.26配置编译规则通过configure脚本指定目标架构、安装路径、依赖等核心参数说明完整配置命令CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_targetaarch64-unknown-linux-musl目标架构对应鸿蒙PC的aarch64-linux-ohos–prefix指定安装路径建议设为源码目录下的target方便后续引用使用make命令进行编译(多线程编译可根据CPU核心数调整-j后的数字加快编译速度)make使用make install命令安装到指定路径–prefix指定的target目录这里是当前源码目录下的geettext_target目录make install1.configure是GNU Autotools生成的配置脚本核心作用是检测环境、适配平台、生成Makefile新手只需掌握“配置→编译→安装”核心三步2.鸿蒙PC交叉编译的核心是通过–hostaarch64-linux-ohos指定目标架构并提前配置鸿蒙PC SDK的交叉编译器环境变量3.鸿蒙PC编译需确保编译器、依赖库均为适配鸿蒙PC的aarch64版本避免混用x86架构的工具或依赖。3.5 确认编译产物安装完成后进入target目录会看到以下核心产物适配aarch64-linux-ohos架构lib/库文件目录包含libintl.so.8核心文件。bin/工具目录包含鸿蒙PC版可执行文件用于验证库可用性如xgettext、msgfmt、msgmerge等这里我们可以看到gettext相关的工具。那么我们可以手写一个C的程序来验证一下库是否可用#includestdio.h#includelocale.h#includelibintl.hintmain(){setlocale(LC_ALL,);bindtextdomain(hello,./locales);textdomain(hello);printf(gettext(Hello, world!\n));return0;}以上代码的作用是这段 C 程序使用 GNU gettext 的国际化框架libintl为字符串“Hello, world!\n”提供按系统语言自动切换的翻译并输出到标准输出。etlocale(LC_ALL, “”)按当前环境变量LANG、LC_ALL、LANGUAGE 等设置程序的区域与编码。空字符串表示“从环境继承”如 zh_CN.UTF-8、en_US.UTF-8。bindtextdomain(“hello”, “./locales”)为消息域 hello 指定翻译文件的根目录。运行时会在 ./locales/textdomain(“hello”)设置当前默认消息域为 hello后续 gettext(…) 就在这个域下查找。gettext(“Hello, world!\n”)以“Hello, world!\n”为消息 ID在 hello 域对应的 .mo 文件中查翻译找不到时返回原文。printf(…)将翻译结果打印到标准输出最后 return 0 正常退出。接下来我们使用鸿蒙PC的clang进行编译将上面写的C程序编译成可执行文件生成中文翻译文件 locales/zh_CN/LC_MESSAGESmkdir-p locales/zh_CN/LC_MESSAGES生成中文翻译文件 locales/zh_CN/LC_MESSAGES/hello.pomsgidmsgstrContent-Type: text/plain; charsetUTF-8\nLanguage: zh_CN\nmsgidHello, world!\nmsgstr你好世界\n编译 .mo 并准备目录结构msgfmt-o locales/zh_CN/LC_MESSAGES/hello.mo locales/zh_CN/LC_MESSAGES/hello.po接下来我们使用clang进行编译将上面写的C程序编译成可执行文件/root/harmonypc/linux/native/llvm/bin/clang--targetaarch64-linux-ohos\-I/root/test/gettext-0.26/geettext_target/include \/root/test/main.c \-L/root/test/gettext-0.26/geettext_target/lib \-lintl-o/root/test/hello_getttext这里最后打包的文件为hello_getttext将hello_getttext拷贝到鸿蒙PC的/root目录下。注意在lib目录下面有一个libintl.so.8文件这个文件是gettext库的动态链接库我们需要将这个文件拷贝到鸿蒙PC的/root目录下。3.6 鸿蒙PC端验证所有文件拷贝到鸿蒙PC之后启动终端执行binary-sign-tool命令分别对hello_getttext进行自签名。先需要进行签名部署在鸿蒙 PC 上部署的程序和库文件完成后需要进行 签名 操作保证安全性与系统兼容性binary-sign-tool sign-inFile \xxxx\hello_getttext-outFile \xxxx\hello_getttext-selfSign1如果出现 “Permission denied” 等错误需要检查当前用户是否有足够的权限执行这些操作或者尝试使用sudo来提升权限我这里使用chmod 755 命令来修改文件权限。接下来执行hello_getttext程序至此鸿蒙PC版的hello_getttext编译移植完成。四、错误处理4.1 错误1Relocations in generic ELF (EM:183) error adding symbols:file in wrong format在编译鸿蒙PC版的geettext时configure已经顺利通过但是执行make命令编译时最后链接阶段遇到如下报错从日志看编译器使用的ohos sdk的clang但是最终链接so时链接器没有使用ohos sdk的lld而是用了系统的ld即使我们定义了LD环境变量也不起作用就导致了最终的链接失败。在CFLAGS里指定了–targetaarch64-linux-ohos架构但是libtool并没有去使用它导致平台架构判断失败使用了错误的链接器。要解决这个问题需要在执行configure命令时给CC环境变量强制追加一个–targetaarch64-linux-ohos参考命令如下所示我们将预先定义好的CFLAGS环境变量追加给CC环境变量即可CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_target重新执行./configure之后重新运行make命令就可以顺利编译通过了。4.2 错误2checking host system type… Invalid configurationaarch64-linux-ohos: OSohos’ not recognizedds-c and-o together...yes checkingforstdio.h...yes checkingforstdlib.h...yes checkingforstring.h...yes checkingforinttypes.h...yes checkingforstdint.h...yes checkingforstrings.h...yes checkingforsys/stat.h...yes checkingforsys/types.h...yes checkingforunistd.h...yes checkingforwchar.h...yes checkingforminix/config.h...no checkingforvfork.h...no checking whether it is safe to define __EXTENSIONS__...yes checking whether _XOPEN_SOURCE should be defined...no checking build system type...x86_64-pc-linux-gnu checking host system type...Invalid configurationaarch64-linux-ohos: OSohos not recognizedconfigure:error:/bin/bash././config.sub aarch64-linux-ohos failed基于OHOS SDK环境对某些C/C应用进行交叉编译时需要指定–hostaarch64-linux-ohos参数以便configure能正常识别目标平台架构和编译器等信息在编译命令时遇到了一个报错在执行configure过程中调用了/bin/bash ./build-aux/config.sub aarch64-linux-ohos但是脚本不识别ohos这个配置导致configure失败更换host为aarch64-unknown-linux-musl更换–host参数重新执行configure命令CC$CC $CFLAGS./configure--hostaarch64-unknown-linux-musl--prefixpwd/geettext_target4.3 错误3Error loading shared library libintl.so.8: No such file or directoryneeded by ./hello_getttext_other接下来尝试运行hello_getttext_other命令发现报错了找不到几个共享库原因是因为这几个共享库文件并不在系统查找动态库的标准路径中。解决办法是设置环境变量LD_LIBRARYA_PATH将共享库所在路径追加到环境变量LD_LIBRARYA_PATH中如下所示假设这几个共享库位于hello_getttext_other命令同一层级下那么我们可以这样设置export LD_LIBRARYA_PATH…/:$LD_LIBRARYA_PATH如下图所示exportLD_LIBRARYA_PATH../:$LD_LIBRARYA_PATH五、总结鉴于鸿蒙操作系统HarmonyOS是一种与Windows、Linux及macOS等传统操作系统不同的新型平台其软件架构和EABIEmbedded Application Binary Interface等特性均采用了全新的设计统一配置鸿蒙SDK的工具链环境变量能从根源上避免编译工具冲突保证交叉编译的一致性和可复现性本次移植的gettext库版本为0.26该版本基于musl libc构建与鸿蒙PC的底层libc完全兼容编译产物无任何依赖问题可直接在鸿蒙PC上稳定运行无崩溃、无内存泄漏。欢迎加入开源鸿蒙PC社区 。
