1. Accueil
  2. Codes-Sources
  3. C / C++ / C++.NET
  4. C++ & C++ .NET

Impossible de lier cmath [Résolu]

Signaler
Messages postés
6577
Date d'inscription
vendredi 28 décembre 2007
Statut
Contributeur
Dernière intervention
9 mars 2020
 -
 vlad -
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++ -m32

LINK_SO =       $(SRCDS_BIN_DIR)/libtier0_srv.so \
			$(SRCDS_BIN_DIR)/libvstdlib_srv.so

LINK_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.
Afficher la suite

9 réponses

Réponse 1 / 9
Messages postés
3805
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
11 mars 2020
 98
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 ?
Réponse 2 / 9
Messages postés
6577
Date d'inscription
vendredi 28 décembre 2007
Statut
Contributeur
Dernière intervention
9 mars 2020
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.
Réponse 3 / 9
Messages postés
3805
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
11 mars 2020
 98
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
Réponse 4 / 9
Messages postés
6577
Date d'inscription
vendredi 28 décembre 2007
Statut
Contributeur
Dernière intervention
9 mars 2020
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-3
cd NoCheatZ-3
git 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.
Réponse 5 / 9
Messages postés
3805
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
11 mars 2020
 98
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).
Réponse 6 / 9
Messages postés
6577
Date d'inscription
vendredi 28 décembre 2007
Statut
Contributeur
Dernière intervention
9 mars 2020
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.
Réponse 7 / 9
Messages postés
6577
Date d'inscription
vendredi 28 décembre 2007
Statut
Contributeur
Dernière intervention
9 mars 2020
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. ;)
Réponse 8 / 9
Messages postés
3805
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
11 mars 2020
 98
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 !
Réponse 9 / 9

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é !
Répondre Posez votre question