无法编译的源代码中有此行#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。这个问题很老了，但它可能会为任何寻找同样东西的人打开大门。