VS2010 et GSL : Problème d'édition de lien.

Version imprimable

21/02/2013, 18h08
eti_nne

VS2010 et GSL : Problème d'édition de lien.

Bonjour,

Je suis nouveau sur ce forum, c'est mon premier post. Je pense qu'il s'agit avant tout d'un manque de connaissance des mécanismes de linkage. Je ne suis pas certain d'être dans la bonne section. Aussi, si je me suis perdu, dites le moi, je me déplacerai :)

ALors voila, j'ai un problème d'édition de lien à la compilation d'un projet Visual Studio 2010 qui utilise GSL 1.8 sur Windows 7 64 bits (edi, lib et platform immuables en raisons de contraintes externes).

J'ai googlé, cherché dans les différents forum, lu la doc officielle, les différents howto que l'on peut trouver, impasse. Au. se. cours.

extrait de l'erreur (même erreur pour autres symbol) :
[...] error LNK2019: unresolved external symbol gsl_odeiv_step_free referenced in function "public: class std::vector<double,class std::allocator<double> > __cdecl [...]

Contexte :
Le projet Visual est généré via CMake, en utilisant un FindGSL.cmake non-officiel que l'on peut facilement googler. J'ai bien l'impression qu'il fonctionne bien (pas d'erreur, et fichiers .lib déterminés).
J'ai généré ces ".lib" à partir des fichiers sources officiels de GSL 1.8 (Release et Static Lib).

J'ai récupéré les fichiers de développeurs, qui sont le suivants :
- libgsl.a
- libgsl.def
- libgsl.dll.a

Ce même projet tourne impeccablement sous Linux (GSL dans un environnement UNIX, rien de bien étonnant).

piste
Je pense que je fais une mauvaise utilisation de ces derniers fichiers.
Je me doute du rôle du .def, à partir du moment ou tous les symbols externes non résolus sont définies en commençant par "GSL_EXPORT ma fonc", et que ce fichier en contiens les exports, nécessaire aux compilateurs non GNU. Cependant, je ne sais pas où se trouve sa place.. Quand aux ".a", il me semble que c'est équivalent d'utiliser les .a ou .lib, s'ils sont compatibles (d'ailleurs, je tombe exactement sur les mêmes erreurs).

Je ne sais pas comment me servir du fichier ".def". J'ai essayé de le passer au /DEF (fichier de definition de module). Je suis à cours d'idée. HELP.
21/02/2013, 19h01
jblecanard

Hello !

Peut-on voir ton CMakeLists.txt ?

Citation:

Envoyé par eti_nne

J'ai récupéré les fichiers de développeurs, qui sont le suivants :
- libgsl.a
- libgsl.def
- libgsl.dll.a

Comment as-tu référencé ces fichiers dans le cache de CMake ?
Es-tu bien sûr d'avoir récupéré la version 64 bits ?
Es-tu bien sûr d'avoir ciblé la plateforme 64 bits dans la config de CMake ?

Es-tu bien sûr d'avoir le compilo Microsoft version 64bits ? Selon la version de Visual Studio que tu utilises, il n'est pas nécessairement installé par défaut, quand bien même ton Windows serait en 64 bits.

Je pense que tout ça doit pouvoir se régler par un petit coup d'"edit cache" de CMake bien senti. Peut-être faudra-t-il rajouter une variable utilisateur à modifier dans le cache pour pointer les fameux fichiers.

Citation:

Envoyé par jblecanard

Comment as-tu référencé ces fichiers dans le cache de CMake ?

Justement, je ne l'ai pas fait. Et ne sais pas comment le faire. Même en customisant le projet VS obtenu, je n'y arrive pas.

Citation:

Envoyé par jblecanard

Es-tu bien sûr d'avoir récupéré la version 64 bits ?

Absolument pas (donc c'est plutôt le contraire). C'est pourquoi je compile moi-même les libs. Le .def est une description, au format texte (indépendantes de la valeur de bitness). Grosso modo, au lieu d'utiliser les .a que j'ai trouvé, j'utilise les .lib. Et je garde le .def, sans vraiment m'en servir.

Citation:

Envoyé par jblecanard

Es-tu bien sûr d'avoir ciblé la plateforme 64 bits dans la config de CMake ?

J'appelle le générateur "Visual Studio 10 Win64". Générateur qui a fait ses preuves dans d'autres projets.

Citation:

Envoyé par jblecanard

Es-tu bien sûr d'avoir le compilo Microsoft version 64bits ? Selon la version de Visual Studio que tu utilises, il n'est pas nécessairement installé par défaut, quand bien même ton Windows serait en 64 bits.

J'ai VS2010 Ultimate Edition version 64 bits.
J'ai déjà utilisé la colonne vertébrale du cmake pour d'autres projet, et cela fonctionnait très bien : je pense que c'est propre à gsl.
De plus, je compile les .lib que j'utilise (si 32, 32 partout).

Citation:

Envoyé par jblecanard

Je pense que tout ça doit pouvoir se régler par un petit coup d'"edit cache" de CMake bien senti. Peut-être faudra-t-il rajouter une variable utilisateur à modifier dans le cache pour pointer les fameux fichiers.

Je croise les doigts. Je pense aussi qu'il faut "simplement" donner l'emplacement des fichiers, et indquer l'usage que l'on en aura. Mais je suis dans le brouillard à partir de la.

Mon CMake n'a rien d'extraordinaire :

Du côté find_package :
Code:

1 2 3 4 5 6 7 LIST(APPEND CMAKE_MODULE_PATH ${GLOB_CMAKE_DIR}) find_package( GSL REQUIRED ) if(GSL_FOUND) message("GSL Found !") endif(GSL_FOUND)
Du côté includes :
Code:

1 2 include_directories(${GSL_INCLUDE_DIRS})
Du côté target_link_libraries :
Code:

1 2 3 add_executable(${BIN_NAME} ${SRC_FILES}) target_link_libraries(${BIN_NAME} ${GSL_LIBRARIES})
Du côté FindGSL.cmake
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 IF(WIN32) # JW tested with gsl-1.8, Windows XP, MSVS 7.1, MSVS 8.0 SET(GSL_POSSIBLE_ROOT_DIRS ${GSL_ROOT_DIR} $ENV{GSL_ROOT_DIR} ${GSL_DIR} ${GSL_HOME} $ENV{GSL_DIR} $ENV{GSL_HOME} $ENV{EXTERN_LIBS_DIR}/gsl $ENV{EXTRA} ) FIND_PATH(GSL_INCLUDE_DIRS NAMES gsl/gsl_cdf.h gsl/gsl_randist.h PATHS ${GSL_POSSIBLE_ROOT_DIRS} PATH_SUFFIXES include DOC "GSL header include dir" ) FIND_LIBRARY(GSL_GSL_LIBRARY NAMES gsl libgsl PATHS ${GSL_POSSIBLE_ROOT_DIRS} PATH_SUFFIXES lib DOC "GSL library dir" ) FIND_LIBRARY(GSL_GSLCBLAS_LIBRARY NAMES gslcblas libgslcblas PATHS ${GSL_POSSIBLE_ROOT_DIRS} PATH_SUFFIXES lib DOC "GSL cblas library dir" ) SET(GSL_LIBRARIES ${GSL_GSL_LIBRARY} ${GSL_GSLCBLAS_LIBRARY} )
En espérant que ça t'inspire !

22/02/2013, 10h15
jblecanard

Re

Et donc il trouve bien tes *.libs et t'affiche le message "GSL Found !" ?

Sous windows, j'ai souvent eu à bricoler le CMake pour lui faire trouver les libs. Tu peux tester la technique suivante: juste avant la directive add_executable, tu rajoutes la ligne suivant:

Code:

link_directories(${GSL_LIBRARY_PATH});

Ensuite tu fais un edit cache et tu rajoutes cette variable à la main dans la liste, tu la mets de type "path" et tu la fais pointer vers le dossier ou il y a tes *.libs.
22/02/2013, 11h05
eti_nne
Citation:

Envoyé par jblecanard

Et donc il trouve bien tes *.libs et t'affiche le message "GSL Found !" ?

Sous windows, j'ai souvent eu à bricoler le CMake pour lui faire trouver les libs. Tu peux tester la technique suivante: juste avant la directive add_executable, tu rajoutes la ligne suivant:

Code:

link_directories(${GSL_LIBRARY_PATH});

Ensuite tu fais un edit cache et tu rajoutes cette variable à la main dans la liste, tu la mets de type "path" et tu la fais pointer vers le dossier ou il y a tes *.libs.

Yes, moi aussi j'ai du pas mal bricoler parfois. Le problème est ici que les libs sont trouvées, linkées, et que c'est insuffisant.

Dans le header gsl, les méthodes sont déterminés avec la macro suivante :
Code:

1 2 GSL_EXPORT gsl_odeiv_control * gsl_odeiv_control_alloc(const gsl_odeiv_control_type * T);
Et que je ne trouve pas la définition de cette macro. Mais elle a certainement un sens. Je pense qu'elle fait le ___cdecl. Et le fait que les fichiers pour développeur soient fournies un .def, cela renforce le sentiment d'un chainon manquant.

Mais sinon, le mécanisme "classique" fonctionne très bien. Je trouve mes .lib, je crée la dépendance. Et hop, il manque des infos. Et hop, je ne sais pas comment faire.
22/02/2013, 15h54
eti_nne

J'ai un petit peu honte. Mais jute un petit peu. Non, en fait, beaucoup.

J'ai eu comme un doute, après ce que tu m'as dit. J'ai vérifié que je généré bien les lib x64 de GSL.. Bingo. C'était les 32 bits. Désolé pour ça. C'est.. Je.. Désolé pour ça.
22/02/2013, 16h39
ternel

ca arrive, et grace à ce passage par le forum, tu seras méfiant pour les prochaines fois…
22/02/2013, 16h59
jblecanard

T'inquiètes les erreurs à la con du genre, tu n'as pas fini d'en faire dans ta vie de développeur... faut accepter le destin, on ne peut pas y échapper :mouarf: