Pourquoi la compilation d'un objet partagé avec GCC entraîne-t-elle toujours des références non définies à main?

Je suis sous Solaris, il est donc possible que cela soit spécifique à l'exécution de GCC sous Solaris. Si j'utilise GCC pour générer un objet partagé, puis exécutez nm sur pour voir des symboles non définis, il y aura toujours une référence à principal:Pourquoi la compilation d'un objet partagé avec GCC entraîne-t-elle toujours des références non définies à main?

[624]  |   0|  0|NOTY |GLOB |0 |UNDEF |main

Si je produis manuellement le même objet partagé en utilisant ld, la référence à la principale n'existe pas. Si je lance nm sur les librairies du systeme dans/usr/lib, aucune d'elles ne semble avoir de references a main. Seules les bibliothèques partagées Je me compile avec GCC.

Les applications compilées sur ces bibliothèques partagées fonctionnent correctement et sans erreur. Mais je ne comprends toujours pas pourquoi la référence à la principale est là en premier lieu. Des indices?

Source

2009-10-16 Joseph Garvin

Pourriez-vous publier la commande que vous utilisez pour compiler votre objet partagé? –

Pour développer le commentaire de Delroth, vous laissez probablement un drapeau que GCC devrait transmettre au chargeur pour lui demander de créer simplement une bibliothèque partagée sans essayer de lier la libc. Si je me souviens bien, appeler gcc avec le drapeau -v lui fera imprimer les commandes exactes qu'il exécute, et montrera les indicateurs qu'il donne à ld. Vous pouvez comparer cela avec votre propre commande ld et cela devrait devenir clair. – Berry

Je ne pense pas qu'il y ait quelque chose d'exotique ici, et il a le -G pour indiquer la création d'une bibliothèque partagée: g ++ -Wl, -R/export/home/joeg/fresh/lib -L/opt/tradelink/g ++ lib6/lib -Wl, -R/opt/tradelink/g ++ lib6/lib -L/opt/app/g ++ lib6/toast-1.1/lib -l/opt/app/g ++ lib6/boost-1.34/lib -Wl, -G -fpic -o libprice.so * .fpo -Wl, -Bstatique -ltoast_datetime -ltoast_assert -ltoast_typeinfo -ltoast_async -lboost_filesystem-gcc42-mt -lboost_date_time-gcc42-mt -lboost_regex- gcc42-mt -lboost_signals-gcc42-mt -lboost_thread-gcc42-mt -lboost_program_options-gcc42-mt -Wl, -Bdynamic -lrt -lpthread –

Vous avez oublié l'option -shared dans votre ligne de commande de lien gcc.

EDIT: et vous avez oublié -fPIC option sur votre ligne de commande de compilation (qui provoque toutes les erreurs de relocalisation au moment de la liaison).

Si vous obtenez toujours des erreurs de réinstallation avec -fPIC sur toutes les lignes de compilation, vous devez reconstruire toutes les bibliothèques d'archives qui vous emmeneront dans (libtoast_datetime, libtoast_assert, etc.) avec -fPIC ainsi.

Source

2009-10-16 18:16:42

Je pensais que c'est ce que le -G a accompli? Quoi qu'il en soit, en essayant "-shared" je reçois un million d'erreurs de liens sur Unwind_resume manquant dans boost. Si j'essaye encore avec "-shared-libgcc" alors je n'obtiens pas d'erreurs, mais le .so a encore une référence à main O_o –

Aussi étrangement ce sont des erreurs de relocalisation de texte, pas des erreurs de référence indéfinies. –

Il s'est avéré que vous aviez raison, mes tests ne fonctionnaient pas car je n'écris pas la ligne de liaison moi-même, mon outil make fait, donc je copiais et collais la ligne de lien générée et la peaufinait, et j'utilisais accidentellement une ligne de lien d'une construction partagée dans un bac à sable statique; p Question distincte - pourquoi cela a-t-il fonctionné dans le passé? Tous les objets partagés ici ont été construits avec -fPIC dans le passé, mais * pas * avec -shared et ont bien fonctionné. Ce n'est pas devenu un problème jusqu'à ce que j'ai commencé à travailler pour rendre le lien plus précis (seulement en tirant exactement ce qui est nécessaire). –

Pourquoi la compilation d'un objet partagé avec GCC entraîne-t-elle toujours des références non définies à main?

Répondre

Questions connexes