☰

dbus 标头的符号链接

tag-icon • tag-icon programming c symbolic-link dbus
dbus 标头的符号链接

无法编译的源代码中有此行#include <dbus/dbus.h> ，但在现实生活中，头文件/usr/include/dbus-1.0/ 与包中存在类似的情况dbus-c++。

为什么 Ubuntu 不提供/usr/include/dbus指向dbus-1.0目录的符号链接？这是软件包中的错误吗dbus？如果是故意的，那么目的是什么？

我自己添加符号链接是一个正确的解决方法吗？

（更改源是不切实际的 - 有很多文件，它们需要与其他人拥有的文件相匹配。）

更新：

好吧，我完全误解了这种情况，但我认为它仍然归结为一个应该通过符号链接解决的问题。声明中提到的 dbus 目录#include是 下的更深层次的目录/usr/include/dbus-1.0/。真正的问题是该文件dbus-arch-deps.h似乎丢失了，但实际上存储在奇怪的位置/usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/。那么现在，为什么 Ubuntu 不在 中提供指向它的符号链接/usr/include/dbus-1.0/dbus，或者实际上将其存储在那里？

答案1

dbus 包含路径应​​通过调用以下方法检索

pkg-config dbus-1 --cflags

你可以通过以下方式使用 dbus 编译程序

cc dbus-example.c -o dbus-example $(pkg-config dbus-1 --cflags)

或者

make dbus-example CFLAGS+="$(pkg-config dbus-1 --cflags)"

dbus 标头包含在以下行中

#include <dbus/dbus.h>

这种“奇怪的包含路径”增加了对 dbus 或其他架构未来版本的灵活性。

答案2

don_jones 的回答似乎涵盖了基本设置的工作方式。但这并不是它应该的样子，它有着很长的发展历史。

为什么？我对此没有太多了解，但我能想到的是：

  • 关于默认位置或符号链接/usr/include/dbus

    系统准备拥有同一个库的多个版本，这些版本不兼容。如果不知道哪个版本是，调试起来会很困难/usr/include/dbus。我说的不是单个库，而是如果所有库都使用这种方法。即使有符号链接，你也必须查找并检查树中的所有链接usr/include，这并不实用。

    因此，编译时标志是解决此问题的最佳方法。但是，您不应该手动设置这些标志，请查看 GNU autotools。这是GNU Autotools 简介。

  • 关于dbus-arch-deps.h

    是的，它应该存储在x86_64-linux-gnu路径中。顾名思义，它是一个依赖于体系结构的标头，您将为每个体系结构找到多个同名文件。从 12.04 开始，Ubuntu 成为多体系结构。（即使在 12.04 之前，您也可以交叉编译不同的体系结构）。

    准确地说：libdbus-1-dev:i386 /usr/lib/i386-linux-gnu/dbus-1.0/include/dbus/dbus-arch-deps.h

    您不必手动包含该标题，但autoconf会处理该问题。

还有其他选择，例如：cmake。这个问题很老了，但它可能会为任何寻找同样东西的人打开大门。

相关内容