在 Ubuntu 上，我倾向于遇到安装在 下的库的链接错误/usr/lib/x86_64-linux-gnu/<libname>，默认情况下似乎不会搜索该库。在最新的示例中，我尝试使用 的 Python 绑定fswatch，它会抱怨，undefined symbol: fsw_init_library因为该fswatch包在下安装共享对象/usr/lib/x86_64-linux-gnu/libfswatch，而 Python（似乎依赖于 gcc）不会搜索它。
我可以硬编码一个标志来将该目录添加到搜索路径中，如下所示，但这看起来非常脆弱，不可移植，而且完全是错误的。
if sys.platform == 'linux':
os.setenv ('LD_LIBRARY_PATH', '/usr/lib/x86_64-linux-gnu/libfswatch')
当我也想用于LD_LIBRARY_PATH其他目的，或者也支持非 x86_64 平台，有多个依赖项遭受此问题等等时，这很快就会变得非常复杂。更糟糕的是，这个咒语根据工具链的不同而有很大不同：上面的代码适用于 Python； Makefile+gcc 还需要其他东西； cmake 可能需要另一个，依此类推。
有没有更好的方法来处理这个问题，避免这种平台、包和工具特定的问题？将这样的库引入范围的“正确”（预期）方法是什么，其包不关心将其放在库搜索路径上？是否有一个神奇的脚本可以以正确的方式设置环境变量？我是否缺少“启用”此类库的设置？像 pkg-config 这样的东西就足够了，但fswatch不附带 pkg-config.pc文件。我在这里以 fswatch 为例，但这并不是我第一次对这个问题感到恼火（尽管我不记得过去事件的具体情况）。
答案1
这有两个方面。
首先是运行时库解析；这就是LD_LIBRARY_PATH配置。处理这种情况的最简洁的方法是在 中创建一个文件/etc/ld.so.conf.d，指向包含该库的目录：
echo /usr/lib/x86_64-linux-gnu/libfswatch | sudo tee /etc/ld.so.conf.d/fswatch-x86_64-linux-gnu.conf
sudo ldconfig
第二个是构建时分辨率；对于这个问题，没有单一的“最佳”解决方案，一个pkg-config文件就已经是您能得到的最好的文件，但您的构建显然需要知道它们应该引用该文件。