Discussion :

[Babcool]

Bonjour à tous,

Je suis en train de travailler sur la remise a plat de la compilation d'un projet en C/C++. On compile tout avec g++ et je suis en train de faire une migration vers cmake (on était anciennement sur un mélange makefile, cmake, script shell et script visual script). J'ai rencontré un problème important lors d'une étape de linkage. g++ me renvoyait plein d'erreur de références non définies liées à boost.

J'ai réussi à trouver que le problème venait de l'ordre des flags. Si je mets les flags de link de bibliothèque avant la liste des fichier .o, ça plante, si je les mets après, ça compile bien.

Première question, pourquoi ? Quel est l'impact de l'ordre des éléments sur la ligne de compile sur le fait que ça link correctement avec boost ?

Deuxième question, comment en utilisant cmake je peux influencer l'ordre des éléments dans les commandes de compilation? Car pour l'instant, il me mets toujours tout mes flags devant, puis tous les fichiers à utiliser pour le linkage?

Pour info, voilà les lignes de commandes qui posent problème (enfin, surtout la première, la 2e étant celle qui marche) :

Ligne qui marche
/usr/bin/ccache g++ -o executable -L/home/babcool/Projet/workspace_c/kernel/CMake/newVersion/../../src/../libs/boost1_49_0/lib -lboost_filesystem -lboost_program_options -lboost_system -lrt -lpthread -m32 <liste des fichiers.o>

Ligne qui ne marche pas (état actuel généré par le cmake)
/usr/bin/ccache g++ <liste des fichiers.o > -o executable -L/home/babcool/Projet/workspace_c/kernel/CMake/newVersion/../../src/../libs/boost1_49_0/lib -lboost_filesystem -lboost_program_options -lboost_system -lrt -lpthread -m32

Quelques infos en plus, la compilation en mode 32 bits est volontaire et nécessaire, les fichiers boost qu'on a sont compilé en mode 32 bits uniquement (vérifié avec objdump).

Merci d'avance pour vos lumières (et vos idées concernant le problème lié à cmake).

Babcool


EDIT après résolution :
Voir les 3 derniers messages. Il ne faut pas mettre le -l avant les .o qui l'utilisent.

Mots clés : cmake bibliothèque undefined reference ordre flag import library

[ternel]

En fait, la documentation du linker g++ explique que -l (et -L) ne s'applique qu'aux arguments à leur droite.
Pourquoi, je l'avais lu, mais je ne m'en souviens plus.
C'est certainement une histoire étrange.

[Babcool]

Oh, surprenant. Merci beaucoup pour l'information.

J'essayerai demain de passer les emplacement avec le TARGET_LINK_LIBRARIES sur CMake pour voir s'il ajoute le flag en début de commande (ce qui résoudrait mon problème).

Est-ce que quelqu'un aurait un lien vers la page de doc en question, pour savoir la raison de ce comportement ? (je ne vois que le fait de linker certains .o avec une bibliothèque particulière, et d'autres avec une autre, mais ça me parait très tordu...). (voir Pps pour un début de réponse).

Babcool

Ps: Je passerai la discussion en résolu demain si ça marche effectivement

Pps : Pour ceux que ça intéresse, voici un lien qui parle un peu du sujet : http://www.network-theory.co.uk/docs...cintro_18.html et la page de doc de gcc, voir "-l" https://gcc.gnu.org/onlinedocs/gcc-4...k-Options.html

[Babcool]

Donc après quelques tests, il ne faut effectivement pas ajouter les flags pour les bibliothèques en utilisant la propriété LINK_FLAGS.

Plusieurs options sont possibles pour faire ça dans cmake. Si il est possible d'utiliser FIND_PACKAGE, c'est le plus simple. Il suffit ensuite d'ajouter le nom de la bibliothèque après la liste des sources dans add_executable.

Dans mon cas, cela n'était pas envisageable, j'ai donc du faire un ADD_LIBRARY avec l'option IMPORTED. Il faut ensuite définir son emplacement avec SET_PROPERTY(<nom de la bibliothèque> IMPORT_LOCATION <chemin vers la bibliothèque>). On peut ensuite ajouter les bibliothèque dans add_executable ou les lier avec TARGET_LINK_LIBRARIES(<nom de l'exécutable> <liste des bibliothèque>).

Merci pour la piste, c'était la bonne .

Babcool

[jblecanard]

Merci pour le retour d'expérience