【鸿蒙pc命令行适配】解决libtool报错：Relocations in generic ELF (EM:183) error adding symbols:file in wrong format

1. 关于libtool

GNU Libtool（简称 libtool）是 GNU 项目推出的一款跨平台编译链接辅助工具，也是开源软件编译体系中（尤其 Autotools 套件）的核心组件。它的核心价值是屏蔽不同操作系统、不同硬件架构、不同编译器的编译 / 链接差异，让开发者用统一的语法编译出适配目标平台的静态库或动态库，无需关注底层工具链的细节差异。libtool 通常与 autoconf、automake 配合使用（合称 Autotools 套件）：

• autoconf：生成configure脚本，检测系统环境、架构；
• automake：生成 Makefile 模板；
• libtool：封装编译 / 链接命令，嵌入到 Makefile 中。

编译开源代码时执行的./configure命令，本质就是通过 autoconf 生成适配对应平台的配置，并生成对应的 libtool 脚本，后续make执行的编译 / 链接命令，实际都是通过 libtool 封装的。

2. 报错表现

编译鸿蒙PC版的curl时，configure已经顺利通过，但是执行make命令编译时，最后链接阶段遇到如下报错：

libtool: link: /home/gyl/harmonypc/ohos-sdk/linux/native/llvm/bin/clang -shared -fPIC -DPIC .libs/libcurl_la-altsvc.o .libs/libcurl_la-amigaos.o .libs/libcurl_la-asyn-ares.o .libs/libcurl_la-asyn-thread.o .libs/libcurl_la-base64.o .libs/libcurl_la-bufq.o .libs/libcurl_la-bufref.o .libs/libcurl_la-c-hyper.o .libs/libcurl_la-cf-h1-proxy.o .libs/libcurl_la-cf-h2-proxy.o .libs/libcurl_la-cf-haproxy.o .libs/libcurl_la-cf-https-connect.o .libs/libcurl_la-cf-socket.o .libs/libcurl_la-cfilters.o .libs/libcurl_la-conncache.o .libs/libcurl_la-connect.o .libs/libcurl_la-content_encoding.o .libs/libcurl_la-cookie.o .libs/libcurl_la-curl_addrinfo.o .libs/libcurl_la-curl_des.o .libs/libcurl_la-curl_endian.o .libs/libcurl_la-curl_fnmatch.o .libs/libcurl_la-curl_get_line.o .libs/libcurl_la-curl_gethostname.o .libs/libcurl_la-curl_gssapi.o .libs/libcurl_la-curl_memrchr.o .libs/libcurl_la-curl_multibyte.o .libs/libcurl_la-curl_ntlm_core.o .libs/libcurl_la-curl_path.o .libs/libcurl_la-curl_range.o .libs/libcurl_la-curl_rtmp.o .libs/libcurl_la-curl_sasl.o .libs/libcurl_la-curl_sha512_256.o .libs/libcurl_la-curl_sspi.o .libs/libcurl_la-curl_threads.o .libs/libcurl_la-curl_trc.o .libs/libcurl_la-cw-out.o .libs/libcurl_la-dict.o .libs/libcurl_la-dllmain.o .libs/libcurl_la-doh.o .libs/libcurl_la-dynbuf.o .libs/libcurl_la-dynhds.o .libs/libcurl_la-easy.o .libs/libcurl_la-easygetopt.o .libs/libcurl_la-easyoptions.o .libs/libcurl_la-escape.o .libs/libcurl_la-file.o .libs/libcurl_la-fileinfo.o .libs/libcurl_la-fopen.o .libs/libcurl_la-formdata.o .libs/libcurl_la-ftp.o .libs/libcurl_la-ftplistparser.o .libs/libcurl_la-getenv.o .libs/libcurl_la-getinfo.o .libs/libcurl_la-gopher.o .libs/libcurl_la-hash.o .libs/libcurl_la-headers.o .libs/libcurl_la-hmac.o .libs/libcurl_la-hostasyn.o .libs/libcurl_la-hostip.o .libs/libcurl_la-hostip4.o .libs/libcurl_la-hostip6.o .libs/libcurl_la-hostsyn.o .libs/libcurl_la-hsts.o .libs/libcurl_la-http.o .libs/libcurl_la-http1.o .libs/libcurl_la-http2.o .libs/libcurl_la-http_aws_sigv4.o .libs/libcurl_la-http_chunks.o .libs/libcurl_la-http_digest.o .libs/libcurl_la-http_negotiate.o .libs/libcurl_la-http_ntlm.o .libs/libcurl_la-http_proxy.o .libs/libcurl_la-idn.o .libs/libcurl_la-if2ip.o .libs/libcurl_la-imap.o .libs/libcurl_la-inet_ntop.o .libs/libcurl_la-inet_pton.o .libs/libcurl_la-krb5.o .libs/libcurl_la-ldap.o .libs/libcurl_la-llist.o .libs/libcurl_la-macos.o .libs/libcurl_la-md4.o .libs/libcurl_la-md5.o .libs/libcurl_la-memdebug.o .libs/libcurl_la-mime.o .libs/libcurl_la-mprintf.o .libs/libcurl_la-mqtt.o .libs/libcurl_la-multi.o .libs/libcurl_la-netrc.o .libs/libcurl_la-nonblock.o .libs/libcurl_la-noproxy.o .libs/libcurl_la-openldap.o .libs/libcurl_la-parsedate.o .libs/libcurl_la-pingpong.o .libs/libcurl_la-pop3.o .libs/libcurl_la-progress.o .libs/libcurl_la-psl.o .libs/libcurl_la-rand.o .libs/libcurl_la-rename.o .libs/libcurl_la-request.o .libs/libcurl_la-rtsp.o .libs/libcurl_la-select.o .libs/libcurl_la-sendf.o .libs/libcurl_la-setopt.o .libs/libcurl_la-sha256.o .libs/libcurl_la-share.o .libs/libcurl_la-slist.o .libs/libcurl_la-smb.o .libs/libcurl_la-smtp.o .libs/libcurl_la-socketpair.o .libs/libcurl_la-socks.o .libs/libcurl_la-socks_gssapi.o .libs/libcurl_la-socks_sspi.o .libs/libcurl_la-speedcheck.o .libs/libcurl_la-splay.o .libs/libcurl_la-strcase.o .libs/libcurl_la-strdup.o .libs/libcurl_la-strerror.o .libs/libcurl_la-strtok.o .libs/libcurl_la-strtoofft.o .libs/libcurl_la-system_win32.o .libs/libcurl_la-telnet.o .libs/libcurl_la-tftp.o .libs/libcurl_la-timediff.o .libs/libcurl_la-timeval.o .libs/libcurl_la-transfer.o .libs/libcurl_la-url.o .libs/libcurl_la-urlapi.o .libs/libcurl_la-version.o .libs/libcurl_la-version_win32.o .libs/libcurl_la-warnless.o .libs/libcurl_la-ws.o vauth/.libs/libcurl_la-cleartext.o vauth/.libs/libcurl_la-cram.o vauth/.libs/libcurl_la-digest.o vauth/.libs/libcurl_la-digest_sspi.o vauth/.libs/libcurl_la-gsasl.o vauth/.libs/libcurl_la-krb5_gssapi.o vauth/.libs/libcurl_la-krb5_sspi.o vauth/.libs/libcurl_la-ntlm.o vauth/.libs/libcurl_la-ntlm_sspi.o vauth/.libs/libcurl_la-oauth2.o vauth/.libs/libcurl_la-spnego_gssapi.o vauth/.libs/libcurl_la-spnego_sspi.o vauth/.libs/libcurl_la-vauth.o vtls/.libs/libcurl_la-bearssl.o vtls/.libs/libcurl_la-cipher_suite.o vtls/.libs/libcurl_la-gtls.o vtls/.libs/libcurl_la-hostcheck.o vtls/.libs/libcurl_la-keylog.o vtls/.libs/libcurl_la-mbedtls.o vtls/.libs/libcurl_la-mbedtls_threadlock.o vtls/.libs/libcurl_la-openssl.o vtls/.libs/libcurl_la-rustls.o vtls/.libs/libcurl_la-schannel.o vtls/.libs/libcurl_la-schannel_verify.o vtls/.libs/libcurl_la-sectransp.o vtls/.libs/libcurl_la-vtls.o vtls/.libs/libcurl_la-wolfssl.o vtls/.libs/libcurl_la-x509asn1.o vquic/.libs/libcurl_la-curl_msh3.o vquic/.libs/libcurl_la-curl_ngtcp2.o vquic/.libs/libcurl_la-curl_osslq.o vquic/.libs/libcurl_la-curl_quiche.o vquic/.libs/libcurl_la-vquic.o vquic/.libs/libcurl_la-vquic-tls.o vssh/.libs/libcurl_la-libssh.o vssh/.libs/libcurl_la-libssh2.o vssh/.libs/libcurl_la-wolfssh.o -lssl -lcrypto -lz -L/home/gyl/openssl-3.0.9/openssl-target/lib -O2 -Wl,-soname -Wl,libcurl.so.4 -Wl,-version-script -Wl,.libs/libcurl.ver -o .libs/libcurl.so.4.8.0 /usr/bin/ld: .libs/libcurl_la-altsvc.o: Relocationsingeneric ELF(EM:183)/usr/bin/ld: .libs/libcurl_la-altsvc.o: error adding symbols:fileinwrongformatclang-15: error: linkercommandfailed withexitcode1(use -v to see invocation)

如下图所示：

从日志看，编译器使用的ohos sdk的clang，但是最终链接so时，链接器没有使用ohos sdk的lld，而是用了系统的ld，即使我们定义了LD环境变量也不起作用。这就导致了最终的链接失败。

3. 解决方案

配置ohos sdk时，设置过这几个环境变量：

exportCC="${OHOS_SDK}/native/llvm/bin/clang"exportCXX="${OHOS_SDK}/native/llvm/bin/clang++"exportLD=${OHOS_SDK}/native/llvm/bin/ld.lldexportCFLAGS="--target=aarch64-linux-ohos -fPIC -D__MUSL__=1"exportCXXFLAGS="--target=aarch64-linux-ohos -fPIC -D__MUSL__=1"

虽然，我们在CFLAGS里指定了--target=aarch64-linux-ohos架构，但是libtool并没有去使用它，导致平台架构判断失败，使用了错误的链接器。要解决这个问题，需要在执行configure命令时，给CC环境变量强制追加一个--target=aarch64-linux-ohos，参考命令如下所示，我们将预先定义好的CFLAGS环境变量追加给CC环境变量即可：

./configure --host=aarch64-linux-ohosCC="$CC$CFLAGS"

重新执行./configure之后，重新运行make命令，如下图所示，就可以顺利编译通过了。

4. 总结

本次鸿蒙PC版curl编译失败的核心，是libtool对交叉编译参数的识别机制限制—— 独立的CFLAGS环境变量无法让其感知--target=aarch64-linux-ohos架构信息，导致误调用系统ld链接器而非鸿蒙 SDK 的ld.lld。解决这类问题的关键原则是：针对基于 Autotools 套件的开源软件，交叉编译时必须将架构核心参数直接追加到CC变量中传递给configure，而非依赖独立环境变量。这一原则适用于所有鸿蒙 PC 平台的开源工具交叉编译场景，可从根源上避免工具链不匹配的链接错误。

欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/ 。