HarmonyOS鸿蒙Next中关于调用go编译的so库出现的问题

HarmonyOS鸿蒙Next中关于调用go编译的so库出现的问题 求大佬帮帮忙
问题描述：

使用cgo 开发 简单 add方法

使用鸿蒙工具链编译so库

使用native封装调用

出现Cannot read property add of undefined错误

不调用go编译的so库，用demo里自带的，是OK的

cgo代码如下

package main

/*
#include <stdlib.h>
*/
import "C"

//export StartXray
func Start(configJSON *C.char) *C.char {
    result := C.GoString(configJSON) + "Got it!"
    if result == "" {
        return nil
    }
    return C.CString(result)
}
func main() {}

使用WSL Ubuntu 22.04系统编译，go版本1.25.4

export GOARCH=arm64
export GOOS=linux
export CGO_ENABLED=1

export LLVMCONFIG=/root/command-line-tools/sdk/default/openharmony/native/llvm/bin/llvm-config
export CGO_CFLAGS="-g -O2 `$LLVMCONFIG --cflags` --target=aarch64-linux-ohos --sysroot=/root/command-line-tools/sdk/default/openharmony/native/sysroot"
export CGO_LDFLAGS="--target=aarch64-linux-ohos -fuse-ld=lld"

export CC="/root/command-line-tools/sdk/default/openharmony/native/llvm/bin/clang"
export CXX="/root/command-line-tools/sdk/default/openharmony/native/llvm/bin/clang++"
export AR="/root/command-line-tools/sdk/default/openharmony/native/llvm/bin/llvm-ar"
export LD="/root/command-line-tools/sdk/default/openharmony/native/llvm/bin/lld"

go build -buildmode=c-shared -v -x -o libtestlib.so testlib.go

这是编译脚本内容

有没有大佬知道怎么解决的


更多关于HarmonyOS鸿蒙Next中关于调用go编译的so库出现的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

https://github.com/golang/go/pull/75048

更多关于HarmonyOS鸿蒙Next中关于调用go编译的so库出现的问题的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


在HarmonyOS Next中调用Go编译的.so库，需确保Go编译器支持生成与鸿蒙系统兼容的二进制文件。目前官方工具链可能不直接支持Go，需通过交叉编译生成适配鸿蒙目标架构（如ARM64）的.so库。编译时需使用正确的CGO_ENABLED标志和CC编译器配置。调用时，需在鸿蒙Native API中通过dlopen和dlsym动态加载符号，并确保内存管理符合鸿蒙规范。

这个问题是由于Go编译的共享库在HarmonyOS Next上导出符号的方式与预期不符导致的。Cannot read property add of undefined错误表明ArkTS/JavaScript侧的Native API绑定未能正确找到并绑定到Go库中的函数。

关键点在于，你导出的函数是StartXray，但在代码中实际定义的函数名是Start。这会导致符号表不匹配。在Go的cgo中，//export StartXray指令指定的是导出到C的符号名，但你的函数定义是func Start(...)。两者必须完全一致。

解决方案：

  1. 修正导出函数名：确保//export指令后的名称与函数定义名称完全一致。

    //export Start
func Start(configJSON *C.char) *C.char {
    // ... 函数体保持不变
}

    或者将函数定义改为func StartXray以匹配指令。

  2. 检查Native API的.d.ts声明文件：在ArkTS侧，你的native封装对应的.d.ts声明文件必须正确声明这个C函数。例如：

    // libtestlib.d.ts
export const Start: (configJSON: string) => string;

    这里声明的函数名Start必须与SO库中导出的C符号名（即经过修正后的Start）完全一致。

  3. 验证SO库的导出符号：使用HarmonyOS NDK中的llvm-nm工具检查编译出的libtestlib.so，确认其中是否存在预期的导出符号（如Start）。

    /path/to/llvm-nm -D libtestlib.so | grep Start

    你应该能看到类似T Start的输出（T表示该符号在文本段，即函数）。如果看不到，说明编译或导出指令仍有问题。

  4. 确保编译目标正确：你的编译脚本中已设置--target=aarch64-linux-ohos，这很关键。继续使用HarmonyOS的LLVM工具链进行编译。

总结步骤：首先统一Go代码中的导出名与函数名；其次确保ArkTS的Native API声明与该名称匹配；最后用工具验证SO库中是否存在该导出符号。通常，修正导出名后问题即可解决。

回到顶部