GCC / C++ Liaison statique pour les en-têtes dans un objet partagé

Question

-J'essaie de créer un objet partagé libfoo.so. libfoo.so est créé à partir de "foo.c". - Supposons que j'inclue les en-têtes "static.h" et "Dynamic.h" dans lesquels je veux que le compilateur
résoudre les symboles pour Static.h et laisser le reste, c'est-à-dire le Dynamic.h, pour le runtime. - Comment dois-je procéder ? Quelles sont les options CFLAG et LDFLAG que je dois passer. - Mon makefile est configuré pour créer un objet partagé en utilisant les CFLAGS=fPIC , shared , W1,export-dynamic. - Dans les chemins d'inclusion, je spécifie l'emplacement correct de "Static.h".

Quelqu'un peut-il m'aider ?

Answer 1

Je crois que la fonctionnalité que vous décrivez est quelque chose que vous obtenez essentiellement gratuitement avec l'éditeur de liens GCC. Pendant le processus d'édition de liens, l'éditeur de liens résoudra tous les symboles de votre code faisant référence aux bibliothèques qui lui ont été transmises sur la ligne de commande. Si le nom du symbole référencé est contenu dans une bibliothèque statique (un fichier .a), il sera lié "statiquement" et si le symbole est, au contraire, dans une bibliothèque de liaison dynamique (un fichier .so), il sera lié dynamiquement au moment de l'exécution du programme.

D'une manière générale, vous ne devriez pas avoir à vous soucier de savoir si vos symboles sont liés statiquement ou dynamiquement, car cela n'a aucun impact sur votre code C/C++. D'après votre description, il est difficile de comprendre la motivation de votre question, mais il est possible que vous ayez besoin de charger explicitement une bibliothèque de liens dynamiques via l'outil de gestion des liens. dlopen() appel système. Si le premier paragraphe ne répond pas à votre question, pouvez-vous décrire le problème général que vous essayez de résoudre ?

Answer 2

Dlopen(), dlfree(), dlsym(), dlerror() sont là pour vous permettre d'ouvrir des bibliothèques d'exécution externes. Vous devez déclarer des pointeurs de fonction vers ces objets externes, puis les résoudre au moment de l'exécution.

Si vous laissez simplement les références "nues" dans le code, l'éditeur de liens tentera de résoudre le symbole. Soit il le résoudra, soit il lancera une erreur, et vous n'obtiendrez pas d'image exécutable. Je ne connais pas d'options de linker pour exclure la tentative de lier des symboles non résolus.

Ou je ne comprends pas ce que vous essayez de faire.

Answer 3

Tant que tous les symboles dynamiques sont pris en compte dans les en-têtes respectifs (via les externs), mais potentiellement non déclarés, ils peuvent être écrasés à des moments ultérieurs par l'éditeur de liens d'exécution lorsqu'une application charge et définit les symboles, et que l'éditeur de liens d'exécution remplit les bits manquants, ou barfs sur l'exécutable si un ou plusieurs symboles sont manquants (comme vous l'avez signalé ci-dessus avec SomeRecord4init).

Vous pouvez également lier votre application à la bibliothèque (au lieu d'utiliser libdl, qui est un casse-tête pour trouver les dépendances de la bibliothèque via de nombreux outils de construction/analyse courants). Pour cela, il suffit d'utiliser -shared et non -static dans vos CFLAGS.

De nombreux projets définissent des API et des champs privés et publics en C pour les bibliothèques. C'est peut-être ce que vous devriez faire pour résoudre ce problème ?