Comportement très étrange dans l'éditeur de liens

Question

C'est étrange car j'ai été en mesure d'obtenir l'erreur ci-dessous pour aller loin en supprimant la référence à libm.

gcc -o example example.o -Wl -L/home/kensey/cdev/lib -L/usr/lib/x86_64-linux-gnu   -lmysqlclient -lpthread -lz -L/usr/lib/x86_64-linux-gnu -lm -lrt -ldl -lcdev -L/home/kensey/www.tools/gplot-lib -lgplot -L/home/kensey/www.tools/gd1_3ret -lgd -lxml2 -lcurl
/usr/bin/ld: /home/kensey/www.tools/gplot-lib/libgplot.a(set.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'
/usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in DSO /usr/lib/x86_64-linux-gnu/libm.so so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

Donc, si je supprime l' -lm de la partie de la commande, je n'ai pas l'erreur. Cependant, je me demande si quelqu'un sait pourquoi la suppression d'une référence à une bibliothèque qui est nécessaire de corriger cela. Comment fonctionne l'éditeur de liens de savoir qui de la bibliothèque de regarder dans? Aussi existe - il un moyen pour interroger un construit exécutable et de dire que la bibliothèque ne vous résoudre la référence à "plancher"? de toute évidence, il se passe quelque chose que je ne comprends pas, et ça m'embête...

Answer 1

L'explication de ce qui se passe est très simple:

1. Votre libgplot.a dépend libm.so, encore de l'ordre de -lm et -lgplot sur le lien de la ligne est faux. L'ordre des bibliothèques sur la ligne de liaison n' importe. En général, le système de bibliothèques (-lpthread, -lm, -lrt, -ldl) doit suivre tout le reste sur la ligne de liaison.

2. Lorsque vous supprimez -lm à partir de la ligne de liaison, libm.so.6 est encore tiré dans le lien par une autre bibliothèque qui apparaît plus tard sur la ligne de liaison (libgd, libxml2 ou libcurl) parce que les bibliothèques dépend libm.so.6. Mais maintenant, libm.so.6 est en bonne place sur la ligne de liaison, et donc tout ce qui fonctionne.

si j'ai mis -lm à la fin de la commande de liaison, d'inscription comme étant le dernier de la bibliothèque, je n'ai pas l'erreur.

Qui confirme l'explication ci-dessus.

Answer 2

J'ai résolu le même problème avec export LDFLAGS="$LDFLAGS -lm"

Answer 3

Peut-être que les chemins de recherche de votre bibliothèque (/ usr / local / lib / ou / usr / lib /, ...) ne contiennent pas de libm à 64 bits, donc gcc ne peut pas le localiser si vous le spécifiez avec le drapeau l . Si vous ne spécifiez que le répertoire, il semble pouvoir trouver le bon. Donc vous pouvez essayer:

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

et utiliser -lm

Answer 4

Difficile de le dire. Parce qu'il y a à la bibliothèque personnalisé répertoires dans la ligne de commande, il est concevable que l' -lm liens une incompatibilité de version alternative. Sans -lm l'éditeur de liens pourrait tirer dans une autre version de lui, car il est requis par l'une des bibliothèques de lien.

Assurez - strace les deux invocations et de voir où libm.so vient dans deux cas.

BTW, -Wl commutateur semble ne rien faire et -L/usr/lib/x86_64-linux-gnu est mentionné deux fois.

Answer 5

Pour ajouter à la liste des réponses, http://fedoraproject.org/wiki/UnderstandingDSOLinkChange C'est informatif. Cela ne concerne pas la question posée ci-dessus, mais l'explication concerne le message d'erreur /usr/bin/ld: note: 'some_reference' is defined in DSO some.so so try adding it to the linker command line