O código-fonte para algo que não será compilado tem a linha #include <dbus/dbus.h> , mas na vida real esse arquivo de cabeçalho está em /usr/include/dbus-1.0/ Existe uma situação semelhante para o pacote dbus-c++ .
Por que o Ubuntu não fornece um link simbólico /usr/include/dbus apontando para o diretório dbus-1.0 ? Este é um bug no pacote dbus ? Se pretendido, qual é o objetivo?
É uma correção adequada adicionar um link simbólico?
(Mudar a fonte não é prático - existem muitos arquivos e eles precisam corresponder ao que outras pessoas têm.)
Atualização:
Ok, eu realmente não entendi bem a situação, embora ainda se trate de um problema que eu acho que deveria ser resolvido por um link simbólico. O diretório dbus referido na instrução #include é um diretório de nível mais profundo em /usr/include/dbus-1.0/ . O problema real é que o arquivo dbus-arch-deps.h parece estar ausente, mas na verdade está armazenado na localização estranha /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/ . Então, agora, por que o Ubuntu não fornece um link simbólico para isso em /usr/include/dbus-1.0/dbus , ou realmente armazena lá?
Os caminhos include dbus devem ser recuperados por uma chamada para
pkg-config dbus-1 --cflags
você pode compilar um programa usando dbus por
cc dbus-example.c -o dbus-example $(pkg-config dbus-1 --cflags)
ou
make dbus-example CFLAGS+="$(pkg-config dbus-1 --cflags)"
cabeçalhos dbus são incluídos pela linha
#include <dbus/dbus.h>
este "caminho estranho inclui" aumenta a flexibilidade para futuras versões do dbus ou outras arquiteturas.
A resposta de don_jones parece cobrir como a configuração básica funcionará. Mas não é como deveria ser, há um longo histórico de desenvolvimento para isso.
Por quê? Eu não tenho muito conhecimento sobre isso, mas o que eu pude pensar:
Sobre a localização padrão ou o link simbólico /usr/include/dbus
O sistema está preparado para ter várias versões da mesma biblioteca que não são compatíveis. Será muito difícil depurar, se não souber qual versão é /usr/include/dbus . Eu não estou falando sobre lib único, mas se todo o lib usou este método. Mesmo com links simbólicos, você encontra e verifica todos os links na árvore usr/include , isso não é prático.
Portanto, os sinalizadores de tempo de compilação são a melhor abordagem para isso. No entanto, você não deve definir esses flags manualmente, dê uma olhada nos autotools GNU. Isso é Uma breve introdução à GNU Autotools .
Sobre dbus-arch-deps.h
Sim, ele deve ser armazenado em x86_64-linux-gnu caminho. Como o nome indica, é um cabeçalho dependente de arquitetura e você terá vários arquivos com o mesmo nome para cada arquitetura. A partir de 12.04, o Ubuntu tornou-se multiarch. (Mesmo antes de 12.04, você pode cruzar compilação, arco diferente).
No preciso: libdbus-1-dev: i386 /usr/lib/i386-linux-gnu/dbus-1.0/include/dbus/dbus-arch-deps.h
Você não precisa incluir esse cabeçalho manualmente, mas autoconf cuidará disso.
Existem outras alternativas, por exemplo: cmake. Esta questão é antiga, mas pode abrir as portas para quem procura a mesma coisa.
Tags symbolic-link programming c dbus