Retrouver la librairie d'un header

Version imprimable

25/05/2016, 20h50
shin101

Retrouver la librairie d'un header

Bonjour à tous,

Alors voila si je prends l'exemple du header math.h , lors de l'etape de l edition des liens , le programme ld ne trouve pas la libraire associée au header math.h.

En utilisant le paramètre -l qui ajoute en prefixe lib et en suffixe .so de la manière suivante -lm pour libm.so qui est la librairie mathematiques l'edition des liens se deroule sans probleme.

Question:
=======

Comment fait-on pour retrouver la librairie qui est liée à un header ? Admettons que le header s'appelle burn.h , si on fait -lb ,comment cela se passe -il s il y a plusieurs librairies contenant b dans leur nom?

Le nom du header est-il toujours en rapport avec le nom de sa librairie?

Je n'ai pas trouvé d'explication sur google.
25/05/2016, 22h16
Obsidian
Bonjour et bienvenue,

Citation:

Envoyé par shin101

Comment fait-on pour retrouver la librairie qui est liée à un header ? Admettons que le header s'appelle burn.h , si on fait -lb ,comment cela se passe -il s il y a plusieurs librairies contenant b dans leur nom?

Le nom du header est-il toujours en rapport avec le nom de sa librairie?

Non, en effet, et c'est effectivement un problème, mais il n'est pas possible d'établir une correspondance directe, ne serait-ce que parce qu'une même bibliothèque peut fournir plusieurs headers distincts, spécialement lorsque l'API est très large et qu'il est opportun de la subdiviser en grands thèmes, mais également parce que cela peut être vrai dans l'autre sens aussi : même si un seul header réunit toute l'API dans un seul fichier, il est possible de se restreindre aux bibliothèques qui se limitent aux fonctions qui nous intéressent tant que notre programme ne fait pas référence lui-même au reste.

Ceci posé, il existe des outils pour gérer ces problématiques mais ils sont généralement propres à une plateforme donnée et sont indépendants du langage C lui-même (et de sa norme en particulier). De là, l'approche générale à adopter est :
- Se référer en premier lieu à la documentation de la bibliothèque concernée qui, en principe, spécifie toujours clairement les deux. Le nom du fichier *.h, c'est certain. La bibliothèque elle-même, c'est un tout petit moins sûr mais, en cas d'absence, cela traduirait quand même un produit mal conçu ou terminé dans la précipitation ;
- Vérifier le contenu de l'archive qui a servi à installer la bibliothèque. Cependant, elle peut être subdivisée en deux parties, l'une pour les binaires proprement dits, nécessaire au fonctionnement des logiciels déjà compilés, et l'autre contenant justement tous les headers, à disposition des programmeurs mais inutiles au grand public.
Puis, sur un Unix, un Linux ou un xBSD en particulier :
- Vérifier le gestionnaire de packages responsable de la bibliothèque en question. Sous Linux, cela peut être apt, rpm ou autre mais, quelque soit le gestionnaire, il te tiendra forcément à disposition une commande permettant de retrouver le package contenant un fichier donné puis de lister le contenu intégral d'un package donné ;
- Vérifier s'il existe un package de développement associé. Il existe en principe un flag spécifique pour faire cette recherche mais, généralement, les packages de développement prennent simplement le nom du package principal muni du suffixe « -dev » ou « -devel » ;
- Utiliser, quand ils sont disponibles et que les packages prennent le soin de les renseigner, des outils tels que pkg-config qui servent à cela.
Pour celui-ci en particulier, tu peux obtenir la liste des packages qu'il connaît grâce à :

Code:

$ pkg-config --list-all

Puis, tu peux l'interroger au sujet du thème qui t'intéresse en fournissant le nom du package suivi d'options précisant la requête. Par exemple, pour savoir quelles bibliothèques il faut impliquer pour utiliser openssl, on écrira :
Code:

1 2 $ pkg-config openssl --libs -lssl -lcrypto
C'est particulièrement utile quand les solutions logicielles mises en œuvre s'appuient elles-mêmes sur d'autres bibliothèques sous-jacentes. Au final, le programmeur doit penser à toutes les inclure en une fois et c'est utile d'avoir un outil pour le faire à notre place. C'est flagrant avec gtk+, par exemple :
Code:

1 2 $ pkg-config gtk+ --libs -lgtk -lgdk -lXi -lXext -lX11 -lm -lglib
26/05/2016, 12h00
shin101

Merci de te reponse bien detaillée.

Je vais me pencher sur l'utilitaire de gestionnaire de paquet, je pense que c'est la meilleure chose à faire.

Un simple commentaire dans le header et tout est réglé,je comprends pas pourquoi aucune lib n'est indiquée dans les headers , mais c'est comme ça.
26/05/2016, 15h12
Obsidian

Citation:

Envoyé par shin101

Je vais me pencher sur l'utilitaire de gestionnaire de paquet, je pense que c'est la meilleure chose à faire.

En effet, mais garde à l'esprit qu'il n'est pas toujours renseigné.

Citation:

Un simple commentaire dans le header et tout est réglé,je comprends pas pourquoi aucune lib n'est indiquée dans les headers , mais c'est comme ça.

D'abord parce qu'en principe, le programmeur n'est pas censé être obligé de se promener dans les headers tant qu'il respecte la documentation. Les man pages, par exemple, débutent toutes par un synopsis qui, pour chaque fonction examinée, indique le fichier *.h à inclure, le prototype de la fonction et les éventuelles macros à définir en cas d'ambiguïtés entre dialectes.

Ensuite, parce que faire cela imposerait une forme particulière au fichier de la bibliothèque, ce qui est en dehors du périmètre du langage C, comme dit plus haut, et qui est spécifique à l'implémentation. Une bibliothèque « biblio » sera vraisemblablement nommée « libbiblio.so » sous UNIX, mais aura des chances de s'appeler « BIBLIO32.DLL » sous Windows, par exemple.

D'autre part, il est bon de rappeler qu'un #include<…> n'est absolument pas l'équivalent d'un import en Java ou en Python. Je pense que l'ambiguïté vient de ça en particulier.

Enfin, et c'est important, tu n'es pas non plus obligé de lier immédiatement ta bibliothèque à ton exécutable dès lors que tu inclus un fichier *.h. D'abord, parce que c'est inutile si tu n'utilises pas les ressources de la bibliothèque (ça peut être intéressant si tu inclus le fichier uniquement pour les types de données qu'il définit), mais également parce que tu peux faire de la compilation séparée et demander à compiler tes programmes sans éditer les liens. Tu obtiens alors des fichiers objet *.o ou *.OBJ dont les références aux ressources extérieures sont laissées « en blanc », et qui peuvent être utilisés ultérieurement pour être assemblés avec d'autres composants qui, eux, fournissent les ressources nécessaires.