gcc statique de la bibliothèque de liaison vs la liaison dynamique

Mon environnement de compilation est CentOS 5. J'ai une bibliothèque tierce appelée libcunit. Je l'ai installé avec les autotools et il génère à la fois libcunit.a et libcunit.so. J'ai ma propre application qui a des liens avec un tas de bibliothèques partagées. libcunit.a est dans le répertoire courant et libcunit.so et d'autres bibliothèques partagées sont dans /usr/local/lib/. Quand je compile comme:

gcc -o test test.c -L. libcunit.a -L/usr/local/lib -labc -lyz

- Je obtenir un lien d'erreur:

libcunit.a(Util.o): In function `CU_trim_left':
Util.c:(.text+0x346): undefined reference to `__ctype_b'
libcunit.a(Util.o): In function `CU_trim_right':
Util.c:(.text+0x3fd): undefined reference to `__ctype_b'

Mais quand je compile avec .so comme:

gcc -o test test.c -L/usr/local/lib -lcunit -labc -lyz

il compile fine et fonctionne très bien aussi.

Pourquoi donne-t-il erreur lorsque lié statiquement à libcunit.a?

OriginalL'auteur bala1486 | 2013-04-16

  1. 6

    Pourquoi donne-t-il erreur lorsque lié statiquement à libcunit.a

    Le problème, c'est que votre libcunit.a a été construit sur un ancien système Linux, et repose sur des symboles qui ont été retiré de libc (ces symboles ont été utilisés dans glibc-2.2, et ont été retirés de glibc-2.3 de plus de 10 ans). Plus exactement, ces symboles ont été hidden. Ils sont mis à disposition pour la liaison dynamique pour les anciens binaires (comme libcunit.so) mais pas de nouveau code peut lier statiquement (vous ne pouvez pas créer un nouveau fichier exécutable ou une bibliothèque partagée qui y fait référence).

    Vous pouvez observer ce comme suit:

    readelf -Ws /lib/x86_64-linux-gnu/libc.so.6 | egrep '\W__ctype_b\W'
   769: 00000000003b9130     8 OBJECT  GLOBAL DEFAULT   31 __ctype_b@GLIBC_2.2.5

readelf -Ws /usr/lib/x86_64-linux-gnu/libc.a | egrep '\W__ctype_b\W'
# no output
    Salut, je suis actuellement à la compilation de cunit projet à partir de la source (cunit.sourceforge.net). Ce n'est pas un binaire précompilé donné à moi. J'utilise les autotools pour l'installer. Une question de plus, la libc.un n'a pas ctype_b symbole. Mais je n'ai pas demandé pour la libc être lié statiquement à mon test de l'application. Il devrait donc être liée de manière dynamique à la libc..6, à droite?

    OriginalL'auteur Employed Russian

  2. 3

    N'avais pas remarqué que le libcunit.a est réellement dans votre cas et le problème avec linakge est plutôt dans la CUnit bibliothèque elle-même. Emploi russe est tout à fait juste, et il ne parle pas de binaires précompilés ici. Nous comprenons que vous avez construit vous-même. Cependant, CUinit lui-même semble être en s'appuyant sur le symbole de glibc qui n'est pas disponible pour la liaison statique plus. Par conséquent, vous n'avez que 2 options:

    1. Déposer un rapport pour les développeurs de CUnit à ce sujet et leur demander de le résoudre;
    2. Utiliser la liaison dynamique.

    Néanmoins, ma recommandation au sujet de votre style d'une liaison statique s'applique toujours. -L. est en général mauvaise pratique. CUnit est une 3ème partie de la bibliothèque et ne doit pas être placé dans le répertoire contenant les fichiers source de votre projet. Il devrait plutôt être installé de la même manière que la version dynamique, c'est à dire que vous avez de la libcunit.so dans /usr/local/lib. Si vous souhaitez d'approvisionnement prefix à Autotools sur l'étape de configuration de CUnit, puis Autotools serait tout installer correctement. Donc, si vous souhaitez lier statiquement à CUnit, pensez à le faire sous la forme suivante:

    gcc -o test test.c -L/usr/local/lib -Wl,-Bstatic -lcunit -Wl,-Bdynamic -labc -lyz
    Cette réponse est incorrecte et que le problème a rien à voir avec la bibliothèque de la commande.
    Russie: Où voulez-vous voir ma réponse à aborder le problème de "bibliothèque de la commande"? Le projet de ligne de commande est juste un copier-coller de l'OP de la ligne de commande avec certains modifié/ajouté drapeaux, mais pas changé de couplage de l'ordre.
    Vous n'avez pas besoin -Wl,-Bstatic si vous liste libcunit.a directement (OP).

    OriginalL'auteur Alexander Shukaev