Manjaro系统中catkin_make编译Git仓库代码时ld无法正确链接Lua库的问题求助

Let’s work through this linker issue step by step. The core problem here is that even though you have Lua 5.2 installed, your catkin_make build isn’t properly linking against the Lua library during compilation—leading to those frustrating undefined reference errors. Since you don’t want to modify the project code, we can resolve this by passing targeted CMake parameters directly to catkin_make.

Try These Solutions (in order) #

1. Clean Old Build Cache First #

Before testing new commands, clear out any stale build artifacts that might be causing hidden conflicts:

catkin clean

2. Specify Lua’s Include and Library Paths Directly #

Most ROS/catkin projects rely on CMake’s FindLua module to locate Lua dependencies. By explicitly telling CMake where your Lua 5.2 files live, you can ensure it uses the correct version instead of defaulting to a mismatched one:

catkin_make -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 -DCMAKE_CXX_STANDARD=14 -DLUA_INCLUDE_DIR="/usr/include/lua5.2" -DLUA_LIBRARY="/usr/lib/liblua5.2.so.5.2"

This command sets two critical variables:

• LUA_INCLUDE_DIR: Points to the directory containing Lua 5.2’s header files
• LUA_LIBRARY: Points directly to the shared library file you confirmed exists on your system

3. Force Linker Flags if Needed #

If the above doesn’t resolve the issue, you can directly pass linker flags to ensure the Lua library is linked into all build targets:

catkin_make -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 -DCMAKE_CXX_STANDARD=14 -DCMAKE_SHARED_LINKER_FLAGS="-llua5.2" -DCMAKE_EXE_LINKER_FLAGS="-llua5.2"

The -llua5.2 flag tells the linker (ld) to explicitly link against the Lua 5.2 library, bypassing any potential gaps in CMake’s automatic dependency detection.

Why This Works #

Your error messages reveal that libflatland_lib.so references Lua functions but wasn’t linked against the Lua library during its compilation. Even though ldd shows it’s dynamically linked to liblua5.2.so.5.2, that only covers runtime linking—compilation-time linking requires explicitly including the library to resolve all symbols upfront.

The extern "C" workaround mentioned on Stack Overflow fixes C++ name mangling (compilers modify function names unless wrapped in extern "C"), but since you don’t want to edit code, setting the CMake variables above ensures the compiler uses the correct headers (which should already include extern "C" guards) and links the right library.

内容的提问来源于stack exchange，提问作者Felix Knopp