PAYATHON 2026

链接时已指定 -fPIC，为什么 GCC 仍提示 Lua 重定位错误？

数据阿明

链接命令中的 -fPIC 无法改变已经编译好的 .o 或 .a 文件。报错指向 /usr/local/lib/liblua.a 中的目标文件，应先检查并修复这个 Lua 静态库，再重新链接绑定库。

目前可以确定本次链接使用的库和导致失败的目标文件，但无法确定几个月前能构建、现在却失败的具体原因。

为什么加了 -fPIC 仍然报错？

-fPIC 主要在编译源文件时生效，用来生成位置无关代码。例如：

gcc -fPIC -c source.c -o source.o

原命令的输入是已经编译好的静态库和目标文件，没有需要编译的 C 源文件。此时添加 -fPIC 不会重新生成这些文件中的机器码。

.a 文件是目标文件的归档。将静态库链接进共享库时，链接器会取出所需的目标文件，这些文件必须满足共享库的重定位要求。

链接器报错指出：

/usr/local/lib/liblua.a(lstate.o): relocation R_X86_64_PC32 against symbol `lua_newstate' can not be used when making a shared object; recompile with -fPIC

这说明当前 lstate.o 中存在不适用于此次共享库链接的重定位。常见原因是 Lua 静态库没有使用 -fPIC 编译。lauxlib.o 中关于 stdin 的警告也提示需要检查 Lua 目标文件的生成方式。

不能仅凭 R_X86_64_PC32 就断言任意目标文件都没有使用 -fPIC。这里的判断依据是链接器明确指出，该重定位针对相应符号不能用于此次共享库链接。

先确认链接器实际选中了什么库

命令中的 -llua 并不保证链接动态库。本次错误已经表明，链接器实际使用的是：

/usr/local/lib/liblua.a

在通常的 GNU/Linux 链接环境中，同一搜索目录内存在可用的共享库和静态库时，-llua 一般优先选择共享库。不过，搜索目录的先后顺序也会影响结果：较早目录中的静态库可能先于较晚目录中的共享库被找到。

可以在原链接命令中加入以下参数，查看链接器处理的输入文件：

-Wl,-t

再检查相关目录中实际安装的库：

ls -l /usr/local/lib/liblua*
ls -l ext/volksdata/build/liblua*

检查共享库是否存在、开发用链接名是否可用，以及 -L 指向的目录是否符合预期。如果库采用带版本的名称，也应核对链接参数是否与之匹配。

方案一：重新构建使用 PIC 的 Lua 静态库

如果需要把 Lua 静态链接进 volksdata.so，应清理 Lua 的旧目标文件，并在重新编译所有相关源文件时加入 -fPIC。

若所用构建系统通过 CFLAGS 传递 C 编译参数，可以加入：

CFLAGS += -fPIC

具体变量和调用方式取决于 Lua 的版本及构建系统。检查实际编译命令，确认 -fPIC 出现在生成 .o 的步骤中。仅修改最终链接命令没有作用。

完成后还要确认：

  • 旧目标文件已经清理，避免继续归档之前的非 PIC 文件。
  • 新生成的 liblua.a 已放到预期位置。
  • 绑定库链接时确实使用了新库，而不是仍然使用 /usr/local/lib/liblua.a 的旧副本。

自己的绑定目标文件和 libvolksdata.a 中被链接进共享库的目标文件也需要满足相同要求。当前报错明确指出的是 Lua；修复后如果出现新的错误，再按错误路径检查其他依赖。

方案二：链接兼容的 Lua 共享库

如果部署环境允许依赖 Lua 共享库，可以改为链接与绑定代码使用的 Lua 头文件和 ABI 兼容的共享库。

对于当前使用的 GNU ld，如果指定目录中确实存在名为 liblua.so 的文件，可以用以下参数明确选择该文件名：

-L/path/to/lua/lib -l:liblua.so

用它替换原来的 -llua，并把示例路径改为实际目录。如果安装文件采用其他名称，应按实际情况调整。

构建成功后，还需要确保运行时动态加载器能够找到该共享库。-L 只设置链接阶段的搜索路径，不会自动设置运行时搜索路径。

为什么没有修改 Makefile，也会突然失败？

Makefile 没有变化，构建时使用的文件和工具仍可能发生变化。可以依次核对：

  • /usr/local/lib/liblua.a 是否被其他安装或构建过程替换。
  • 原先使用的 Lua 共享库或符号链接是否消失，导致现在选中静态库。
  • 编译器、链接器、库搜索路径或环境变量是否变化。
  • 之前是否复用了已有的 volksdata.so，而这次才真正重新执行链接。

这些都是排查方向，不能仅凭当前错误认定某一项就是原因。要确定变化来源，需要对比之前成功构建的完整日志、实际链接库路径，以及相关库文件的版本或校验值。

备注：内容仅供参考。