Le programme a-t-il besoin de symboles supplémentaires de la bibliothèque partagée .so à l'exception de ceux déclarés dans le fichier d'en-tête?

Question

En programmation C, j'ai pensé qu'un fichier objet peut être lié avec succès à un fichier .so tant que le fichier .so offre tous les symboles qui ont été déclarés dans le fichier d'en-tête. Supposons que j'ai foo.c, bar.h et deux bibliothèques libbar.so.1 et libbar.so.2. L'implémentation de libbar.so.1 et libbar.so.2 est totalement différente, mais je pense que c'est OK tant qu'ils offrent tous les deux des fonctions déclarées dans bar.h.

J'ai lié foo.o avec libbar.so.1 et produit un exécutable: foo.bin. Cet exécutable a fonctionné quand libbar.so.1 est dans LD_LIBRARY_PATH (bien sûr, un lien symbolique est fait comme libbar.so) Cependant, quand je change le lien symbolique en libbar.so.2, foo.bin n'a pas pu fonctionner et s'est plaint :

undefined symbol: _ZSt4cerr 

libbar.so.1 est une bibliothèque C++ construit, tandis que libbar.so.2 est une bibliothèque construite en courant alternatif. Je ne comprends pas pourquoi foo.bin a besoin de ces symboles liés à C++ seulement significatifs dans libbar.so.1 lui-même, puisque foo.bin est construit sur du code c pur foo.c.

Answer 1

_ZSt4cerr est évidemment un nom C++ tronqué. Vous devrez peut-être vérifier si vous utilisez le bon compilateur (gcc/g ++, je sais que cela semble stupide, mais j'ai rencontré une telle confusion;)), et s'il y a des macros dans le fichier bar.h qui pourraient avoir cerr référencé

Answer 2

Vous devez démêler le nom C++ avant la recherche. Pour gcc, il existe un utilitaire C++ filt:

$ c++filt 
_ZSt4cerr 
std::cerr 

Il s'agit simplement du flux de fichier d'erreur standard.

Answer 3

Vous avez probablement oublié de lier l'ensemble du programme à la bibliothèque standard C++.

Answer 4

L'affirmation dans la question est fausse. Vous dites, 'le fichier d'en-tête.' Il n'existe pas de 'le fichier d'en-tête (un et unique).' Si vous voulez dire 'le fichier d'en-tête déclarant une certaine classe C++', eh bien, cette classe pourrait hériter d'autres classes. Ou il pourrait utiliser des exceptions. Ou RTTI. Dans ce cas, par défaut, le .so contenant le code qui l'accompagne contiendra des «symboles indéfinis suspendus». Par défaut, on s'attend à ce que le programme 'principal' soit en C++ et qu'il soit lié à l'environnement d'exécution C++.

Il est possible pour créer un .so autonome, mais vous devez faire un travail supplémentaire pour le créer. Vous devrez peut-être utiliser -Bsymbolic ou spécifier des bibliothèques -l lors de la liaison, ou les deux. Cette zone n'est pas bien documentée et nécessite généralement une certaine archéologie.