web-dev-qa-db-fra.com

lien symbolique pour les en-têtes dbus

Le code source de quelque chose qui ne compile pas a la ligne #include <dbus/dbus.h> mais dans la vie réelle, ce fichier d'en-tête est dans /usr/include/dbus-1.0/ Il en est de même pour le package dbus-c++.

Pourquoi Ubuntu ne fournit-il pas un lien symbolique /usr/include/dbus pointant vers le répertoire dbus-1.0? S'agit-il d'un bogue dans le package dbus? Si prévu, à quoi sert-il?

Est-ce une solution appropriée d'ajouter un lien symbolique moi-même?

(Changer la source n’est pas pratique - il y a beaucoup de fichiers et ils doivent correspondre à ceux des autres.)

Mise à jour:

Ok, j’ai totalement mal compris la situation, même s’il s’agit toujours d’un problème qui, à mon avis, devrait être résolu par un lien symbolique. Le répertoire dbus mentionné dans l'instruction #include est un répertoire de niveau plus profond situé sous /usr/include/dbus-1.0/. Le vrai problème est que le fichier dbus-Arch-deps.h semble être manquant, mais est en réalité stocké à l'emplacement bizarre /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/. Alors maintenant, pourquoi Ubuntu ne fournit-il pas un lien symbolique à ceci dans /usr/include/dbus-1.0/dbus, ou ne le stocke pas réellement là-bas?

programmingcsymbolic-linkdbus
6
DarenW

les chemins dbus include sont destinés à être récupérés par un appel à

pkg-config dbus-1 --cflags

vous pouvez compiler un programme en utilisant dbus en

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

ou

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

les en-têtes dbus sont inclus par la ligne

#include <dbus/dbus.h>

ces "chemins d'inclusion bizarres" augmentent la flexibilité vis-à-vis des futures versions de dbus ou d'autres architectures.

6
don_jones

la réponse de don_jones semble couvrir le fonctionnement de la configuration de base. Mais ce n'est pas comme cela devrait être, il y a une longue histoire de développement pour ceci.

Pourquoi? Je n'ai pas beaucoup de connaissances à ce sujet, mais voici à quoi je pourrais penser:

  • À propos de l'emplacement par défaut ou du lien symbolique /usr/include/dbus

    Le système est prêt à avoir plusieurs versions de la même bibliothèque qui ne sont pas compatibles. Il sera trop difficile de déboguer, si vous ne pouvez pas savoir quelle version est /usr/include/dbus. Je ne parle pas de simple lib, mais si tout a utilisé cette méthode. Même avec des liens symboliques, alors vous avez trouvé et vérifié tous les liens dans l’arborescence usr/include, ce n’est pas pratique.

    Donc, les indicateurs de temps de compilation sont la meilleure approche pour cela. Cependant, vous ne devriez pas définir vous-même ces indicateurs manuellement, jetez un coup d'œil sur les GNU autotools. Ceci est ne brève introduction à GNU Autotools .

  • À propos de dbus-Arch-deps.h

    Oui, il devrait être stocké dans le chemin x86_64-linux-gnu. Comme son nom l'indique, il s'agit d'un en-tête dépendant de l'architecture et vous aurez plusieurs fichiers avec le même nom pour chaque architecture. À partir de 12.04, Ubuntu est devenu multiarch. (Même avant 12.04, vous pouvez effectuer une compilation croisée, un autre Arch).

    En précision: libdbus-1-dev: i386/usr/lib/i386-linux-gnu/dbus-1.0/include/dbus/dbus-Arch-deps.h

    Vous n'avez pas à inclure cet en-tête manuellement, mais autoconf s'en chargera.

Il existe d'autres alternatives, par exemple: cmake. Cette question est ancienne, mais elle peut ouvrir la porte à quiconque cherche la même chose.

0
user.dz