Impossible de lier cmathRésolu

Question

Bonjour, 

Voilà 2 jours que j'essaie de compiler un projet x86 depuis une machine x64 (Debian).
Tout fonctionnait bien sur une machine ubuntu x86 mais là ...

J'utilise g++ 4.7.2.

J'ai cherché plusieurs fois sur google, sans succès.

Le linker n'arrive tout simplement pas à résoudre les symbols tels que __pow_finite utilisés dans une autre bibliothèque statique du projet.

J'ai changé de place l'option -lm, je l'ai même mis partout à la fois ... sans succès.

Voici un extrait du makefile :

CXX = g++ -m32LINK_SO =       $(SRCDS_BIN_DIR)/libtier0_srv.so \			$(SRCDS_BIN_DIR)/libvstdlib_srv.soLINK_A =        $(SRCDS_A_DIR)/tier1.a -lm -ldl \			$(SRCDS_A_DIR)/mathlib.a LINK = -Wl,--as-needed,--no-undefined $(LINK_A) $(LINK_SO)@$(CXX) $(INCLUDE) $(CFLAGS) $(OBJECTS) $(LINK) -shared -o $(BINARY_DIR)/$(BINARY_NAME)  2> "error_link.txt";

mathlib.a a besoin de math.h.
D'autres sources du projet appellent cmath

Voici un extrait des erreurs du linker :

/mathlib.a(mathlib_base.o): In function `MatrixAngles(matrix3x4_t const&, float*)':/mathlib/mathlib_base.cpp:247: undefined reference to `__atan2f_finite'

Voici le ldd du binaire :

linux-gate.so.1 =>  (0xb7784000)        libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb76bb000)        ./bin/libtier0_srv.so (0xb768e000)        ./bin/libvstdlib_srv.so (0xb758c000)        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb74a0000)        libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb747a000)        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb745d000)        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb72f9000)        /lib/ld-linux.so.2 (0xb7785000)        librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb72ef000)        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb72d6000)

Cependant, lors du chargement dans l'application, j'ai les même erreurs que le linker.
 
Avez-vous une idée pour corriger ce problème s'il vous plait ?

Je n'en peut plus, vraiment je n'ai plus d'autre solution que de solliciter votre aide.

Merci.

cptpingu · Answer

Bonjour.

Difficile de te répondre comme cela, sans voir la totalité (à vrai dire une archive contenant ce qu'il faut, prêt à compiler serait plus simple pour t'aider sur un souci de compilation). Si tu peux mettre une archive téléchargeable, je pourrais essayer de la compiler chez moi.
À première vue, à froid, le -shared n'est-il pas utilisé pour générer un *.so et non un exécutable ?

SypayV · Answer

Je veux bien te passer toute la source (Qui se trouve sur github, il faut juste que je commit mes erreurs dessus), mais pour arriver à compiler le projet il faut télécharger au moins un SDK de 340 Mo.

L'idée c'est bien de générer une bibliothèque dynamique (Il s'agit d'un plugin).

https://github.com/L-EARN/NoCheatZ-3/tree/debian-amd64-issue

Tu pourras en voir un peu plus sur ce que j'essaie de faire, par contre pour compiler ça va être une autre histoire ...

Merci pour ton aide.

cptpingu · Answer

Peux-tu m'écrire une procédure de téléchargement, installation, compilation ?
(En gros,  je télécharge quoi, et comment je compile chacun des parties ?)

J'ai à dispo un g++4.6 (sous unbuntu 12.04 64bits), un g++4.4.5 (sous debian squeeze 64bits), qui sont différents de ce que tu as. J'espère que ça n'influera pas.
 
Edit: Je viens de comprendre que c'est le submodule qui télécharge tout seul le sdk.


Améliorer votre expérience CodeS-SourceS avec ce plugin:
http://codes-sources.commentcamarche.net/forum/affich-10000111-plugin-better-cs-2#cptpingu-signature

SypayV · Answer

Il n'y a pas besoin de compiler le sdk. On s'en sert juste pour avoir les en-têtes.

Pour le reste, c'est décrit sur le readme.

Ce qui va changer pour toi, pas besoin non plus d'installer le serveur de jeux (On s'intéresse uniquement à la compilation).

Ce qui change pour le clonage :

git clone -b debian-amd64-issue git://github.com/L-EARN/NoCheatZ-3.git NoCheatZ-3cd NoCheatZ-3git submodule update --init --recursive

Et il faudra penser à copier ces fichiers dans server-plugin/bin pour le lien dynamique : http://www.filedropper.com/css-libs

Edit : Peu importe la version de g++, au contraire plus ça fonctionne sur différentes et mieux ce sera. Le fait que tu sois sous x64 c'est parfait aussi, mais vu qu'on compile quand même pour x86 il faut penser à avoir les versions x86 de libc.

cptpingu · Answer

Je n'ai pas réussi à la compiler (je ne parle pas de linker, mais bien de compiler).
En fait, je ne comprends pas comment ça pourrait compiler en l'état. Par exemple dans Preprocessor.h, il y a un "#include "Platform.h". Or il n'y a pas de "Platform.h" à ce niveau. En faisant un "find", il y a apparemment plein de "Plateform.h" un peu plus haut dans l'arborescence, mais il n'est indiqué nul part avec lequel se lier.
Je précise que j'utilise uniquement le makefile fournit (en tapant un simple make en ligne de commande). S'il y a des chemins personnalisés, liés à un éditeur en particulier, je ne vais pas pouvoir faire grand chose.
(À noter aussi qu'il y a une erreur dans le makefile, il y a une tabulation qui traine ligne 140, et la tabulation a un sens grammatical. Mon éditeur (emacs) a été assez sympa pour me le signaler :p).

SypayV · Answer

Il y a beaucoup de fichiers qui se trouvent dans les SDK.
Le makefile se charge d'utiliser le bon SDK en fonction du jeu pour lequel on fait le plugin.
Donc il inclue les en-têtes spécifiques, tels que Platform.h par rapport au dossier du SDK dont le jeu dépend.

C'est pourquoi il faut utiliser le makefile avec, par exemple, make debug GAME=CSS ou alors make release GAME=CSGO, etc ...
Un simple make n'incluera pas le sdk et donc plein d'erreurs ...

Mais je pense que mon problème vient des changements ABI, encore et toujours ... Apparemment c'est sensé fonctionner correctement avec g++-4.1 ... Je vais ajouter le SDK spécifique à CSS et essayer d'utiliser les bibliothèques fournies dedans, je croise les doigts.

En attendant tu peux réessayer de compiler, si tu veux bien.

SypayV · Answer

J'ai réussi à résoudre mon problème en utilisant le SDK spécifique.
ça va encore ajouter 400 Mo de source dans le projet mais bon ...

Edit : A mon avis ça aurait été plus simple de compiler mathlib moi même, ça revient au même.

Merci pour ton aide et tes retours en tous cas, je te décharge de tout ça.

Bonne journée. ;)

cptpingu · Answer

J'avais encore des soucis de compilation, malgré l'utilisation des bonnes options à make ^^.
Je ne vois pas trop le rapport entre un nouveau SDK et le link avec -lm, peut être que c'est proprement indiqué/linké dans celui-ci au contraire de l'autre. Mais bon, peu importe, si tu as réussi à résoudre ton souci, tant mieux !

vlad · Answer

Je ai eu le même problème que vous, voilà ce que j'ai fait xD:

kludge.c:
#include <math.h>

extern float __atan2f_finite(float x, float y){
  return atan2f(x,y);
}

extern double __atan2_finite(double x, double y){
  return atan2f(x,y);
}

extern double __log_finite(double x){
  return log(x);
}

extern double __pow_finite(double x, double y){
  return pow(x, y);
}

extern float __acosf_finite(float x){
  return acos(x);
}

extern double __asin_finite(double x){
  return asin(x);
}

extern double __acos_finite(double x){
  return acos(x);
}

$> gcc kludge.c -c$> ar -r mathlib.a kludge.o

... et ça a marché !

Impossible de lier cmath

9 réponses

Votre réponse