我必须使用以下可怕的CMake代码将应用程序的一个库与NVIDIA CUDA静态库合并：
GET_TARGET_PROPERTY(OUTPUT_LIB ${LIBNAME} LOCATION)
add_custom_command (TARGET ${LIBNAME}
POST_BUILD
COMMAND mv ${OUTPUT_LIB} ${OUTPUT_LIB}.old
COMMAND echo "create ${OUTPUT_LIB}" > combineLibs.mri
COMMAND echo "addlib ${OUTPUT_LIB}.old" >> combineLibs.mri
COMMAND echo "addlib ${CUDA_LOCATION}" >> combineLibs.mri
COMMAND echo "save" >> combineLibs.mri
COMMAND echo "end" >> combineLibs.mri
COMMAND ar -M <combineLibs.mri
COMMAND rm ${OUTPUT_LIB}.old
COMMENT "Building merged library for ${LIBNAME} at ${OUTPUT_LIB}, including ${CUDA_LOCATION}"
)
target_link_libraries(${LIBNAME} -pthread -c)
这样会成功生成一个合并的静态库，其中包含所有符号。但是，NVIDIA CUDA静态库以未解析的符号形式依赖于libpthread和libc。现在，合并的库中还包含那些未解析的符号，并且该target_link_libraries行似乎没有按照我认为的方式执行，因为这些符号在链接时没有得到解析。如何获取合并的静态库以动态链接到libpthread和libc？
这the target_link_libraries条线确实没有按照您的想法做。
target_link_libraries(目标,选项只有在目标是由链接器生成的内容时，才)具有将链接器选项选项添加到目标链接的预期效果。如果在目标的生产中没有链接发生，则该指令将无效。
您的目标是静态库。链接程序不会生成静态库（与程序不同，不同于动态/共享库）。正如您custom_command实际上所说明的，静态库是由GNU通用归档程序产生的ar。它只是档案的存档，而档案恰好是目标文件，但就ar它们而言，它们也可能是Documents，Pictures和Music文件夹的内容。由于静态库的生产中不涉及任何链接，因此无法与静态库进行任何链接。
一个ar归档可以用作接头的输入中的的东西的联动是由链接器产生-一个程序或一个共享库。在那种情况下，链接器将查看档案，以查看是否包含进行链接所需的任何目标文件。如果找到，它会从存档提取出来，并联系他们到程序中。该链接将与您在链接器命令行中列出了所需的对象文件而根本没有提及存档一样。
但是，如果链接器从存档中提取的任何目标文件都带有未定义的引用，那么要使其解析，必须在想要链接器的程序或共享库的链接中链接一些定义了这些引用的库。产生-就像您必须解决输入到链接的任何其他对象文件中的未定义引用一样。
所以，
如何获取合并的静态库以动态链接到libpthread和libc？
你不能 这没有道理。静态库中对象文件的任何库依赖关系只能通过链接这些对象文件而获得了这些依赖关系的程序或共享库的链接来满足。
最后，-c不是GCC链接选项会导致请求的链接libc。它根本不是链接选项。这是一个指示GCC前端不调用链接器的选项。它被传递给GCC以请求不进行链接的编译，并且将其包含在CMaketarget_link_libraries指令中的不良影响是将阻止目标的任何链接发生。
如果你想的明确要求联动libc，使用-lc，下列链接器使用协议-lname的请求的联动libname。
也许您-c是libc从要求链接的假设推断出-pthread要求链接的libpthread。实际上，-lpthread将要求链接libpthread。该选项-pthread是用于编译和链接的更抽象的GCC选项，这意味着对于该平台，做正确的事情即可与Posix Threads库链接-这可能需要传递-lpthead给链接器，而不一定要传递给链接器。
这样-pthread 就可以了，target_link_libraries因为它具有请求Posix Threads链接的效果，但是请参阅cmake和libpthread的答案，以获取适当的CMake方法。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句