CMake FindPackage(PythonLibs):CMake是否优先考虑动态库或静态库? [英] CMake FindPackage(PythonLibs): Does CMake give a preference to dynamic or static libraries?

查看:748
本文介绍了CMake FindPackage(PythonLibs):CMake是否优先考虑动态库或静态库?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我运行FindPackage(PythonLibs)时,它将首先找到静态python库python3.5m.a,而不是python3.5m.so.这是CMake的预期行为吗?我怀疑它不是按照 CMake错误报告进行的;但是,此错误报告已于2005年提交.情况在13年内发生了变化.如果共享库具有优先权,那么您知道为什么CMake会在共享库之上找到静态库吗?

When I run FindPackage(PythonLibs), it finds the static python library first, python3.5m.a, rather than python3.5m.so. Is this the expected behavior of CMake? I suspect that it is not as per CMake bug report; however, this bug report was submitted in 2005. Things change over 13 years. If shared libraries have preference then any idea why CMake would find a static library over a shared one?

我已经通过使用SET()命令告诉CMake我自己的构建正确的库在哪里来解决构建问题.我正在寻找一个答案,可以更好地了解这种情况下的CMake行为,因为我正在尝试解决其他

I have already fixed the build issue by just telling CMake where the proper library is for my own build using the SET() command. I'm looking for an answer which leads to a better understanding of CMake's behavior in this context because I'm trying to solve a different problem, and finding the static over the shared library seemed odd to me. Thanks!

系统/问题信息:

  • Ubuntu 16.04,64位
  • 已编译并启用了共享的Python 3.5.5
  • CMake 3.11.0
  • 按照Tsyvarev注释进行共享库和静态库位于同一目录中

如果您查看cmake文件,特别是第142-163行的FindPythonLibs.cmake(CMake 3.11.0),在我看来,它找到的是共享库,然后是静态的,但我又不是专家CMake(这是一个CMake菜鸟,试图在很少的上下文中挑选出源代码的作用).

If you look at the cmake files, specifically FindPythonLibs.cmake (CMake 3.11.0) at lines 142-163, it looks to me that it finds the shared library then the static, but again I'm not an expert at CMake (it is a CMake noob trying to pick out what the source code does with very little context).

感谢您抽出宝贵的时间阅读该问题.任何帮助表示赞赏.

Thank you for taking time from your day to read this question. Any help is appreciated.

18-4-13

嗯,这很有趣.我检查了CMAKE_FIND_LIBRARY_SUFFIXES变量,值是:.so.a".对于我来说,这几乎足以使我了解如何根据此问题来调试CMake文件/answer .当/如果我能解决它,我会再次更新我的帖子.

Well, this is interesting. I checked the CMAKE_FIND_LIBRARY_SUFFIXES variable, and the value was: ".so.a". This is almost becoming interesting enough for me to figure out how to debug CMake files as per this question/answer. When/If I get around to it, I'll update my post again.

编辑4/16/18

好吧,我开始加紧准备调试过程.在准备时,我发现了错误.构建共享版本的python 3.5.5时,我忘记删除CMakeCache.txt,因此FIND_PACKAGE命令没有重新运行.谢谢您抽出宝贵时间回答这个问题,Tsyvarev.我学到新东西.

Well, I started gearing up to do the debugging process. As I was gearing up, I figured out the mistake. I forgot to delete the CMakeCache.txt when I built the shared version of python 3.5.5, so the FIND_PACKAGE command was not re-running. Thank you for taking your time replying to this question, Tsyvarev. I learned something new.

推荐答案

如果静态库和共享库都在同一目录中,则可以尝试通过

If both static and shared libraries are in the same directory, you may try to specify preferences of libraries via CMAKE_FIND_LIBRARY_SUFFIXES variable:

# Prefer dynamic libraries to static ones
set(CMAKE_FIND_LIBRARY_SUFFIXES ".so" ".a")

在重新搜索库之前,请不要忘记清除CMake缓存(构建目录中的CMakeCache.txt文件).

Do not forget to clear CMake cache (CMakeCache.txt file in the build directory) before re-search the library.

将库位于同一目录中的要求很重要:

Requirement for libraries to be located in the same directory is important:

find_library 命令的标准算法会搜索所有可能的库在切换到下一个目录之前,先在目录中命名.此行为已通过 NAMES_PER_DIR 选项更改,但很少在查找"脚本中使用.

Standard algorithm of find_library command searches all possible library names in a directory before switching to the next directory. This behavior is changed by NAMES_PER_DIR option, but it is rarely used in "Find" scripts.

这篇关于CMake FindPackage(PythonLibs):CMake是否优先考虑动态库或静态库?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆