Est-il possible de lier à des symboles non externes, ou les convertir en symboles externes?Possibilité de lier des symboles non externes?
Je demande simplement parce qu'une (grande) bibliothèque que je veux utiliser a une compilation nocturne, mais avec des symboles dépouillés. Je préfère utiliser la nuit, plutôt que de passer une demi-journée à la compiler.
Stripped bibliothèque signifie uniquement que les symboles de débogage ont été supprimés. Le reste de la bibliothèque est en place. Le problème que vous pourriez rencontrer en liant à une telle bibliothèque est un avertissement de l'éditeur de liens concernant les symboles de débogage manquants. Un autre problème que vous pourriez rencontrer avec une bibliothèque dépouillée est le débogage sans les symboles de débogage appropriés, c'est un peu amusant. À la question des symboles externes/non-externes (voulez-vous dire exportés?), Si vous liez à la bibliothèque statique, il n'a pas besoin de définir des 'exports' car il est lié à votre code juste comme un gros fichier objet. Liaison à la bibliothèque dynamique, diffère légèrement selon la plate-forme qui vous intéresse. Sur Windows, votre DLL doit déclarer la fonction que vous souhaitez utiliser comme (declspec) __dllexport. Sur linux si la mémoire me sert, il n'y a pas besoin de déclarer quoi que ce soit de ce genre et vous pouvez utiliser vos fonctions du fichier .so comme si elles seraient dans votre code, de manière similaire aux bibliothèques statiques.
Mise à jour:
Alex, je ne suis pas sûr à 100%, mais je crois, ce que j'ai écrit sur Linux applique à OS X dans ce cas. Tant que vous avez un fichier d'en-tête avec des déclarations de fonction, vous devriez pouvoir les utiliser correctement. Si vous n'avez pas certaines fonctions dans le fichier d'en-tête fourni, mais que vous avez accès aux sources, vous pouvez créer les vôtres. C'est cependant une assez mauvaise idée, puisque les auteurs du SDK ne voulaient pas vous donner accès à ces fonctions et ne les ont pas ajoutés aux fichiers d'en-tête publics, ils sont donc libres de modifier leurs fonctionnalités comme ils le souhaitent à tout moment , vous laissant potentiellement avec le code non-travail et un besoin de réécrire/re-concevoir certaines choses. La même chose s'applique à toutes les fonctions «sans papiers», elles peuvent être modifiées ou supprimées et si cela vous cause un problème, vous êtes la seule personne coupable, et la seule personne qui s'en soucierait. Procéder avec prudence.
Non. Il n'est pas possible de lier des symboles non externes. Par définition, les symboles non-externes ne sont pas exportés du compilateur/assembleur/quoi que ce soit vers l'éditeur de liens. Ces symboles sont partis, disparus de l'univers, seulement une mémoire qui s'estompe, au moment où l'éditeur de liens voit le (s) module (s) à lier. Au début de l'âge du fer, lorsque les ordinateurs étaient encore fabriqués à partir de transistors discrets, les compilateurs et les assembleurs pouvaient être commandés pour imprimer des tables de symboles pour chaque module. Aujourd'hui, nous appelons cela "informations de débogage", il n'est généralement PAS imprimé, mais stocké quelque part que les outils de débogage peuvent trouver dans le module de chargement. Et c'est précisément ce qui est retiré de votre construction nocturne.
Qu'est-ce que vous essayez de faire? Si vous essayez d'accéder à des routines (ou des variables) dans la bibliothèque qui ne sont explicitement pas externes, eh bien, il y a probablement une bonne raison pour qu'elles ne soient pas externes. Parlez aux responsables de la bibliothèque, expliquez pourquoi vous voulez accéder à ces routines (ou variables), et ÉCOUTEZ leurs explications sur les raisons pour lesquelles ils n'ont pas fourni cet accès.
Mais les symboles existent toujours - si je fais 'nm -m WebCore' je peux les voir, je ne peux pas les lier (car ils ne sont pas externes). La raison pour laquelle ils sont privés, est que WebCore est un cadre général pour WebKit, et WebKit fournit une API publique à WebCore. Malheureusement, cette API est seulement Objective C, pas C++, d'où la raison pour laquelle je veux le contourner. Je crains ne pas être possible cependant. –
Je suis enclin à dire non, tant que la question est générale.
L'éditeur de liens peut par exemple effectuer des optimisations d'appelant/appelé sur des fonctions internes qu'il ne peut pas exécuter pour des fonctions externes. Par exemple. il peut détecter qu'aucun des appelants ne se soucie de la conservation d'un certain registre, et optimiser la sauvegarde du registre dans le code prologue de l'appelé.
Je sais qu'il est vieux, mais je cherchais la même chose, semble que cette technique pourrait travailler:
http://en.wikibooks.org/wiki/Reverse_Engineering/Mac_OS_X#Example
Désolé, je ne suis pas très précis. C'est un framework OSX (donc une bibliothèque dynamique). La bibliothèque n'exporte que certains symboles - la plupart d'entre eux sont «non externes». Je me demande si je peux avoir accès à ces symboles non externes. –