Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Source code for something that won't compile has the line #include but in real life that header file is in /usr/include/dbus-1.0/ Similarsituation exists for the dbus-c++ package.

Why doesn't Ubuntu provide a symlink /usr/include/dbus pointing to the dbus-1.0 directory? Is this an bug in the dbus package? If intended, what it the purpose?

Is it a proper fix to add a symlink myself?

(Changing the source is not practical - there are many files, and they need to match what other people have.)

update: ok, I totally misunderstood the situation, though it still comes down to a problem I think should be solved by a symlink. The dbus directory referred to in the #include statement is a deeper level directory under /usr/include/dbus-1.0/. The real problem is that the file dbus-arch-deps.h appears to be missing, but is actually stored in the weird location /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/ so now - why doesn't ubuntu provide a symlink to this in /usr/include/dbus-1.0/dbus, or actually store it there?

share|improve this question
add comment

1 Answer 1

dbus include paths are meant to be retrieved by a call to

pkg-config dbus-1 --cflags

you can compile a program using dbus by

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

or

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

dbus headers are included by the line

#include <dbus/dbus.h>

this "weird include paths" increase the flexibility towards future versions of dbus or other architectures.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.