-1
votes

La liaison G ++ est-elle statique ou dynamique de Libusb et de Pthreads?

Lorsque vous ajoutez -LUSB-1.0 code> et -Pthread code> à la commande compilation, sont-ils statiquement ou dynamiquement liés?

libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007fc4662b7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc465af7000)


1 commentaires

S'il vous plaît fournir une autre exemple de reproductible minimal dans votre question et définissez explicitement que voulez-vous dire par statisme. Si LDD mentionne une bibliothèque, il s'agit d'un objet partagé (car toute bibliothèque statique libfoo.a n'apparaîtra pas dans la sortie de LDD )


3 Réponses :


1
votes

Les objets partagés peuvent être liés au moment de la compilation et sont chargés au démarrage du programme ou peuvent être chargés de manière dynamique au moment de l'exécution avec Dlopen.

"lors de l'ajout de commandement de compilation, sont-ils Lié de manière statique ou dynamique? " EM> Si le compilateur trouve des bibliothèques dynamiques, il s'agit de liens contre eux. Sinon, il relie les bibliothèques statiques. P>

Ceci P>

libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007fc4662b7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc465af7000)


2 commentaires

Les bibliothèques partagées sont liées à la fois au moment de la construction et à l'exécution.


@BasileSyTaryNkebitch je n'ai pas dit le contraire mais je ne l'ai peut-être pas très clair.



0
votes

Je suis confus. S'il est chargé de manière dynamique, comment sont résolus les symboles?

Notez que Linux est Open Source , afin que vous puissiez télécharger et étudier le code source < / h1>

(du noyau , du GCC Compiler C et C ++ et sa bibliothèque standard C ++, du Binutils linker, de libc ou MUSL-LIBC , de Gnu emacs , de gdb , de libusb .....).

sur Linux, les bibliothèques sont de préférence et par défaut (si disponibles) bibliothèques partagées. Donc, la liaison dynamique par gcc ou g ++ est la préférence implicite. Si aucune bibliothèque partagée n'est trouvée, une bibliothèque statique est liée.

Avant de lire le Livre Dragon , un bon C ++ Livre de programmation , le liant et chargeurs livre, le Bibliothèque de programmes HOWTO Assembleur HOWTO , < Un href = "https://tldp.org/howto/c++-dlopen/index.html" rel = "nofollow noreferrer"> C ++ Dlopen Howto , Dlopen (3) , ld.so (8) , adv Programmation de Linux ponctuelle , quelque manuel sur Systèmes d'exploitation , Syscalls (2) , elf (5) , et le C ++ 11 standard N3337 et Drepper's < Un href = "https://www.akkadia.org/drepper/dsohowto.pdf" rel = "nfollow noreferrer"> Comment écrire des bibliothèques partagées papier. Voir aussi le Projet Refpersys (projet de logiciel libre que j'ai créé qui utilise dlopen pour C ++ code ).

Prenez l'habitude d'activer Informations de débogage DNAFOWE (pour utiliser ultérieurement le gdb débogueur) et avertissements lors de la compilation, donc DO g ++ -wall -wextra -g -c src1.cc -o obj1.o et remarquez que Ordre des arguments à g ++ comporte. Et g ++ est en train d'exécuter d'autres programmes ( cc1plus , comme , ld ). Pass -v à g ++ pour découvrir lesquels.

Je pensais que .So ne peut être chargé qu'avec Dlopen

Non, la liaison dynamique LD.SO (8) est en cours de chargement des bibliothèques partagées et peut être invoquée par Exclusion (2 ) . Utilisez LDD (1) , Strace (1) , PROC (5)

lire aussi Programmation de vous-même dans dix ans et voir Linux de zéro


0 commentaires

1
votes

Lorsque vous ajoutez -Lusb-1.0 et -Pthread à la commande compilation, sont-ils liés de manière statique ou dynamique?

Par défaut, les bibliothèques partagées sont liées à Linux. Sauf si vous demandez une liaison statique, les bibliothèques partagées respectives Pour -pthread et -LUSB-1.0 sera lié. Vous pouvez dire à la liaison que vous souhaitez une liaison statique via l'option -static si vous avez besoin).

.so est un objet partagé. Je suis confus. S'il est chargé de manière dynamique, comment sont résolus les symboles?

Il est dynamiquement lié ​​ - non chargé lors de la compilation. Mais il y a quelques travaux effectués par la liaison statique ( LD ) En cas de compilation, de sorte que lorsque les bibliothèques sont chargées au moment de l'exécution par la liaison dynamique ( LD.SO ), il sait localiser les symboles.

Que se passe-t-il au moment de la compilation, c'est que la liaison statique crée des adresses «Stub» pour les symboles dans les bibliothèques partagées dans la section PLT ( Table de liaison de procédure ). Au moment de la charge de programme (ou lorsque les symboles sont référencés), la liaison / chargeur dynamique "remplit" ces adresses aux adresses réelles effectuées via le got ( Table de compensation globale ). Donc, la résolution et le chargement des symboles réels sont effectués au moment de l'exécution, mais avec une aide de la liaison statique à la compilation.

Je pensais que .So ne peut être chargée qu'avec Dlopen et pour obtenir l'adresse d'un symbole, on utiliserait DLSYM.

Ce n'est pas vrai. Les bibliothèques partagées peuvent être liées à la fois au moment de la compilation et ouvertes à l'exécution via dlopen . C'est beaucoup plus commun à un lien à l'heure de compilation que d'ouverture via dlopen . À peu près tous les fichiers binaires du système sont en fait liés dynamiquement sur Linux; La liaison dynamique est la valeur par défaut sur tous les systèmes Linux modernes.

Découvrez drepper's Comment écrire des bibliothèques partagées si vous êtes intéressé par les détails .


1 commentaires

Merci, j'apprécie la réponse détaillée. Je vais certainement regarder le papier le week-end.