Question

我的问题与.so共享库有关。我正在构建一个在一台ubuntu机器上使用cmake但在另一台ubuntu机器上运行该应用程序的项目。

在CMakeLists.txt文件中，我有以下几行：

project (clientapp)

add_executable(${PROJECT_NAME} ${SOURCES} ${WAKAAMA_SOURCES} ${SHARED_SOURCES})

LINK_DIRECTORIES(/home/user//mraa-master-built/build/src)
target_link_libraries (clientapp libmraa.so)
target_link_libraries(clientapp m)

这些行将两个库libmraa.so和数学库添加到可执行文件中，并在另一台机器上成功运行。

我对共享库的理解是它们必须在编译时出现，并在应用程序启动时出现。但我没有其他机器上的libmraa.so文件，应用程序运行正常。我希望它不起作用。

我的假设是否正确？

Answer 1

一般来说，gcc and clang support lazy linking/binding of symbols, but not for entire libraries。这意味着所有共享对象（即：dlopen()文件）应至少在应用程序启动时出现。此的一个例外是，如果您修改了makefile以不链接这些库，并通过dlsym() / libmraa.so等手动调用库函数。

这些库中单个符号的绑定可以推迟到需要时，或者您可以强制在启动时解析所有符号using -z lazy or -z now, respectively。

奇怪的是，您的应用程序在没有ldd app_name的情况下运行。在没有库的情况下运行应用程序的两个最可能的原因是：

您的应用程序未使用库中定义的任何符号，因此链接器会在构建时忽略库（尝试ldd并查看您的库是否存在于{{1}提供的库列表中}）。
您的构建脚本中存在某些问题，并且您正在静态链接到库的.a存档。

编辑：为了响应应用程序如何知道如何查找库，您的链接器（在这种情况下为ld）将使用rpath查找来确定要访问哪些目录用于搜索适当的库。您可以通过从命令行执行LD_DEBUG=libs app_name之类的操作来查看其工作原理。您还可以通过LD_LIBRARY_PATH=/some/path app_name添加额外路径。

Answer 2

我的假设是否正确？

是

对应用程序运行的原因有两种可能的解释：

你错了，机器上某处 libmraa.so（虽然可能不在你看的地方），或者
默认情况下，您的编译器默认为-Wl,--as-needed，而您的二进制文件实际上 依赖于libmraa.so，尽管它出现在您的链接线上。

您可以轻易地确认或反驳上述任何一种猜测。

要确认猜测2，请执行以下操作：

readelf -d clientapp | grep NEED | grep libmraa # if there is no output, guess 2 is correct

如果猜测2错误，要确认猜测1，请执行此操作（在没有libmrra.so的计算机上）：

ldd clientapp | grep libmraa.so # if guess 2 is incorrect, and this command produces no output, then # your dynamic loader is broken, which is very unlikely.

在所有情况下，是否需要在运行时存在.so库

2 个答案: