我尝试在正在为基于ARM的Zynq平台进行交叉编译的应用程序中使用 ncurses 及其姊妹库表单。
链接器死了，抱怨它无法找到libncurses.so.5
我一直在寻找这个错误，解决方案通常涉及安装32位版本的libncurses。但是，在这种情况下，这是一个32位的分布开始，所以我没有理由相信这是一个32/64位的东西。
这令人费解，因为CMake最初似乎能够找到有问题的库：
我创建了＆＃34; FindNCurses＆＃34;和＃34; FindForm＆＃34; cmake模块找到这些库。模块使用find_path和一些建议的搜索路径。这些路径指向我的目标rootfs（即系统的暂存rootfs，我将复制此应用程序）。
在CMakeLists.txt中使用message（）语句，我可以看到＆＃34; FindXYZ＆＃34;模块确实填充了NCURSES_LIBRARIES和FORM_LIBRARIES变量以及相关.so文件的绝对路径。
但是，在生成的link.txt个文件中，我看到ncurses库.so的绝对路径已替换为-L / -l </ p>的组合
表单库的绝对路径保持不变。
因此我希望如此：
/project/linux/software/build/linux/rootfs/stage/usr/lib/libncurses.so
/project/linux/software/build/linux/rootfs/stage/usr/lib/libform.so
但我实际上得到了这个：
-L/project/linux/software/build/linux/rootfs/stage/usr/lib
-lncurses
/project/linux/software/build/linux/rootfs/stage/usr/lib/libform.so
深入挖掘，我发现.../stage/usr/lib仅包含libncurses.so，但不包含libncurses.so.5。此外，libcurses.so似乎不是一个真正的.so文件，而是一个ld脚本：
INPUT(libncurses.so.5 AS_NEEDED(-ltinfo))
这是正常的事吗？我想这就是＆＃34; libncurses.so.5＆＃34;来自，但libncurses.so.5文件肯定不存在。它可以在.../stage/lib中找到（但/ usr）
libform.so和libform.so.5确实存在于.../stage/usr/lib下.../stage/lib下
libform.so包含实际代码，而不是ld脚本。
我是否错误地使用了CMake的查找过程？ 或者是我的分阶段Linux rootfs没有正确创建（即librcurses.so.5实际上是否存在于usr / lib下）？我使用的是Xilinx的自动化工具（Petalinux），所以我对这些工具的组装方式无法控制。
有关可能发生的事情的任何见解？我应该将/lib/libncurses.so.5个文件复制到/usr/lib/吗？
谢谢！
编辑：我尝试将libcurses.so.5文件从/ lib复制到/ usr / lib，现在一切都在编译。我需要等到我开始在目标系统上尝试它。我进行更改的目录是自动生成的，所以这绝对不是一个长期的解决方案。
编辑2 ：我使用的是CMake 2.8.11，但没有理由阻止我升级。我需要与其他队友协调升级，但这是可能的。
编辑3 ：取得了一些进展： 我升级到CMAKE 3.3.x，但似乎没有解决问题。 我尝试使用内置的＆＃34; Find Curses＆＃34;模块，我似乎需要设置CMAKE_PREFIX_PATH以指向目标系统的rootfs的本地副本。它似乎是在我认为正确的地方找到libncurses.so（PREFIX / usr / lib）
我仍然看到CMAKE将ncurses库的绝对路径转换为-l / -L组合：
-lncurses
-L(CORRECT PREFIX)/usr/lib
链接器应该如何知道它需要转到PREFIX / lib才能找到.so.5文件？
它们应该在同一个目录中吗？ 在我看来，libncurses.so中声明的路径应该正确指向.so.5文件。我尝试将路径更改为指向.so.5文件的绝对路径，它也可以工作。
似乎我找到的唯一解决方案是确保.so.5文件是.so文件应该是的位置（有意义，但默认情况下，这个Petalinux发行版似乎放了由于某种原因，不同目录中的文件。）
我开始怀疑这是否只是我正在使用的Petalinux工具/发行版中的一个错误...
由于