./libwiringPi.so: undefined reference to `fcntl@GLIBC_2.28'交叉编译wiringPi库遇到了这个错误

这个错误通常是由于交叉编译时使用的 glibc 版本与目标系统上的 glibc 版本不兼容导致的。GLIBC 2.28 是在较新的 glibc 版本中引入的函数，如果您的目标系统上的 glibc 版本低于 2.28，则会出现该错误。
解决这个问题的一种方法是更新目标系统上的 glibc 版本，以便与编译时使用的版本匹配。如果您无法更新目标系统上的 glibc 版本，可以尝试降低编译时使用的 glibc 版本。
另外，还可以尝试使用静态链接方式编译 wiringPi 库，这样可以避免对目标系统上的动态链接库依赖。您可以在交叉编译时指定 -static 参数，或者修改 Makefile 文件以使用静态链接。
希望这些方法对您有帮助！如果您还有其他问题，请随时提问。

相关问题

/libtorch/lib/libtorch_cpu.so：对‘fcntl64@GLIBC_2.28’未定义的引用 /root/下载/libtorch/lib/libtorch_cpu.so：对‘log2@GLIBC_2.29’未定义的引用 /root/下载/libtorch/lib/libtorch_cpu.so：对‘pow@GLIBC_2.29’未定义的引用 /root/下载/libtorch/lib/libtorch_cpu.so：对‘exp2@GLIBC_2.29’未定义的引用 /root/下载/libtorch/lib/libtorch_cpu.so：对‘exp@GLIBC_2.29’未定义的引用

解决方案分析
问题描述
当前问题是 libtorch_cpu.so 动态链接库在运行时报告了对 GLIBC_2.28 和 GLIBC_2.29 的未定义引用。这表明该动态库依赖于较新的 glibc 版本，而目标系统的 glibc 版本较低。

已知条件解析

目标环境的 glibc 版本根据提供的信息[^2]，目标系统上的 glibc 支持到 GLIBC_2.27，而不支持更高版本的功能（如 GLIBC_2.28 或 GLIBC_2.29）。

第三方动态库无法重新编译提供的信息[^3]指出，某些第三方动态库（如 libsqlite3.so）已经存在类似的兼容性问题，并且这些库无法被重新编译以适配低版本的 glibc。

服务器上 glibc 升级受限国产操作系统仅能兼容至 glibc 2.28，这是其最高版本限制。

交叉编译工具链配置方法参考信息[^4]展示了如何通过自定义构建 glibc 来满足特定需求。

技术解决方案
方法一：静态链接替代动态链接
如果可能，可以尝试将 libtorch_cpu.so 中使用的标准 C 库函数替换为静态链接的方式。具体操作如下：

使用 -static-libgcc 和 -static-libstdc++ 编译选项来确保 GCC 运行时库以静态方式嵌入。
对于其他依赖项，可以通过指定路径手动引入静态版本的库文件。例如：gcc -o my_program main.o -L/path/to/static/libs -l:libpthread.a -lm -ldl

需要注意的是，这种方法可能会显著增加最终二进制文件的大小。

方法二：定制化 glibc 构建
为了使应用程序能够在旧版 glibc 上正常工作，可以选择在一个隔离环境中安装并使用较高版本的 glibc。以下是实现步骤：

下载对应版本的 glibc 源码包（如 glibc-2.28），解压后进入源目录。
配置跨平台编译参数，类似于以下命令：./configure --prefix=/opt/custom_glibc --build=$(uname -m)-linux-gnu --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc

执行编译过程：make && make install

将生成的共享库复制到目标设备的目标位置，并调整 LD_LIBRARY_PATH 环境变量指向新版本的 glibc 路径。

此方法的优点在于无需修改现有应用逻辑即可解决问题；缺点则是增加了部署复杂度以及潜在的安全风险。

方法三：降级 libtorch_cpu.so 的依赖关系
考虑到直接降低 libtorch 自身对于现代 libc 的要求较为困难，建议采取间接手段——即寻找预编译好的、基于更老版本 glibc 构建而成的 libtorch 发布版本。可以从官方仓库或者社区贡献者处获取适合您场景的需求版本。
另外也可以考虑利用 Docker 容器技术封装整个开发测试流程，在容器内部维持一致性的软件栈组合从而规避外部干扰因素影响。

示例代码片段
下面给出一段简单的脚本用于验证所选策略是否生效：
import ctypes

try:
sqlite_lib = ctypes.CDLL('libsqlite3.so')
torch_lib = ctypes.CDLL('libtorch_cpu.so')
except OSError as e:
print(f"Error loading libraries: {e}")
else:
print("Libraries loaded successfully.")

上述 Python 程序试图加载两个有问题的 so 文件，若无异常抛出则说明修复成功。

总结
综上所述，针对 libtorch_cpu.so 存在的 GLIBC 不兼容情况提供了三种可行的技术路线图。每种都有各自适用范围及局限之处，请依据实际项目约束挑选最合适的处理办法实施下去。

libgio-2.0.so: undefined reference to `fcntl64@GLIBC_2.28'

回答: 这个错误是由于在链接过程中找不到fcntl64@GLIBC_2.28的定义所引起的。[1]解决这个问题的方法是找到xxxxxlibc.so的源码，在本地进行编译，然后将编译出来的动态库替换掉原来的库，再重新执行编译命令。这样就可以解决libgio-2.0.so: undefined reference to fcntl64@GLIBC_2.28'`的问题。[2]如果你需要构建交叉编译器，你可以下载相应的软件进行构建。[3]
引用[.reference_title]

1 [安装fastdfs出现/usr/local/lib/libfastcommon.so: undefined reference to `fcntl64@GLIBC_2.28](https://blog.csdn.net/appleyuchi/article/details/105103652)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2allinsert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item]
2 对‘fcntl@GLIBC_2.28‘未定义的引用[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2allinsert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item]
3 libwiringPi.so:undefined reference to ‘fcntl@GLIBC_2.28[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2allinsert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item]
[ .reference_list ]