Comment s'appliquent -fvisibility option de symboles dans les bibliothèques statiques?

Je partage un projet de bibliothèque qui est construit à partir de 4 bibliothèques statiques (.a) et un objet (.o) fichier. Je suis en train d'ajouter la -fvisibility=hidden option pour limiter les symboles de la sortie pour seulement ceux que je marque dans la source avec un __attribute__.

J'ai ajouté le -fvisibility=hidden option pour les options de compilation pour le .so projet (qui couvre la .o fichier) et pour la .a projets.

Les symboles dans l'objet fichier sont supprimés comme prévu à partir de la dernière .so. Cependant, les symboles de la .a projets sont encore à l'étape de .so fichier. L'ajout de la -fvisibility=hidden option pour le .so lien de commande n'a aucun effet.

Ce que je fais mal?

Mon but ici est de supprimer à partir de la .so tous les symboles, sauf les fonctions de l'interface de la bibliothèque.

EDIT: en fait j'ai utilisé un carte de la version pour résoudre cela pour l'instant. Cependant, il exige le maintien de la version de script externe des symboles de changement. Accepté de répondre a une meilleure idée.

Plate-forme ne sont pas mentionnés, mais pour une solution pour le faire sous iOS/OS X, reportez-vous à stackoverflow.com/a/18949281/316487

InformationsquelleAutor Steve Fallows | 2010-02-08

30

Fondamentalement, la visibilité est traitée lors de la liaison, et l'éditeur de liens ne semblent pas l'imposer sur la statique des archives. Une question connexe (mais pas un doublon) a été demandé sur DONC ici.

Ce que je vous conseille de faire est de remplacer votre étape de lien: gcc -shared -o mylib.so foo.o libbar.a dans un de deux étapes du processus où vous récupérer des fichiers de l'objet:
- ar x libbar.a (éventuellement dans une adaptées, répertoire vide)
- gcc -fvisibility=hidden -shared -o mylib.so foo.o tempdir/*.o
- Belle idée. Correspond avec ce que j'ai appris par l'expérimentation. Peut-essayer plus tard.
- J'aimerais juste préciser où est le bon endroit pour ajouter -fvisibility=hidden. Selon le GCC Visibilité Wiki dans la section Comment utiliser le nouveau C++ visibilité support il est dit que modifier votre système pour passer d'-fvisibility=cachés à chaque appel de la GCC compiler un fichier source.. Donc je me demandais si vous avez vraiment besoin pour définir la visibilité du pavillon lors de la construction de la sorte d'objet.
- Quelle sera la différence entre -fvisibility=hidden et -s?
InformationsquelleAutor F'x
59

Simplement passer -Wl,--exclude-libs,ALL à gcc

Cela indique à l'éditeur de liens pour transformer tous les symboles dans les bibliothèques statiques pour caché.

--exclude-libs accepte également une liste des archives (c'est à dire statique de la bibliothèque de noms) pour une granularité plus fine sur laquelle les bibliothèques pour masquer les symboles de.

Remarque: cela ne fonctionnera que dans les systèmes à l'aide de GNU binutils (par exemple Linux) ou avec un éditeur de liens de soutien --exclude-libs (par exemple, il ne fonctionnera pas avec OSX est ld64)
- Merci beaucoup! J'utilise cette avec -fvisibility=cachés et de manière sélective uniquement à l'exportation de l'API publique (OMI seulement la liste blanche de l'approche est saine d'esprit, spécialement quand il s'agit de bibliothèques statiques externes au projet). Peut-être que si vous pouvez ajouter des étiquettes à l'avenir Googleurs seront reconnaissants.
- Je crois que c'est -Wl,--exclude-libs=TOUS (remplacer le deuxième virgule avec un =)
- Malheureusement cela ne fonctionne pas sur Mac OS depuis ld ne connaît pas cette option sous Mac OS.
- Aussi, --exclude-libs n'est applicable que sur les bibliothèques statiques non pas sur les bibliothèques dynamiques.
- La question est plus précisément sur les bibliothèques statiques
- Ce que j'ai remarqué, c'est que ce ne sera pas fiable exclure les symboles si la compilation avec lien-l'optimisation du temps.
- Cela m'a aidé beaucoup, j'ai passé beaucoup de temps à essayer de cacher inutile symboles qui traite aussi de compilateur de bugs qui ne seront pas à définir la visibilité correctement dans certains cas. Mais cette collaboration avec la visibilité=caché juste résout des choses et le fait fonctionner comme prévu. Je ne suis pas totalement sûr de savoir pourquoi ce n'est pas le comportement par défaut pour les bibliothèques partagées.
InformationsquelleAutor fons
4

C'est une réponse au problème pour OS X.

Le Mac ld ne prend pas en charge --exclude-libs, mais il prend en charge -exported_symbol sym et il ne l'appliquer à l'objet des fichiers de bibliothèques statiques. Et quand vous êtes de filtrage pour une API publique, la liste blanche est assez petit pour l'énoncer.

J'ai fini par le suivant dans mon Makefile pour générer un -Wl,-exported_symbol,_api_func_1 drapeau export pour chaque symbole:
```
SYMBOLS   = api_func_1 api_func_2 api_func_3 api_func_4
SYMBOLS   += api_func_5 # add more as necessary
COMMA     = ,
LDFLAGS   += $(addprefix -Wl$(COMMA)-exported_symbol$(COMMA)_,$(SYMBOLS))

# ...

libmyapi.so: # ...
    $(CC) -shared -o $@ ... $(LDFLAGS)
```
Ensuite, vous pouvez si-porte entre cette version des drapeaux et la GNU ld version après la détection de l'éditeur de liens qui le système a.

InformationsquelleAutor Riking

Vous devez vous connecter pour publier un commentaire.