Discussion :

[TocTocKiéLà?]

Bonjour,
depuis longtemps je compile des logiciel -non ecrit par moi même- via la console en tapant des commandes comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
./configure
make
make install

par contre j'ai toujours que travaillé avec code::blocks. Aujourd'hui j'aimerais faire comme les grands et me passer d'IDE.

Le problème ? avec code::block je me contenté de lui dire dans quels répertoires cherches les lib, include...
alors qu'avec un makefile il faut taper des fichiers comme configure.ac galère galère quand on un un projet avec plein de fichier et qui cherche des en-tête à l'autre bout du disque dur dans un dossier reculé...

ce problème ma semblé résolu quand j'ai découvert autotools. Problème les tuto que j'ai trouvé disent d'employer autoscan et de renommer le fichier de sortie configure.scan en configure.ac... et bien j'ai des erreurs lorsque je tape make...

et le pire c'est que aucun tutorial que j'ai vu ne précise comment définir un dossier contenant des fichiers en-têtes qui se situe dans un dossier lointain...

et bien entendu il y a quand même des fichiers à taper à la main!...


CMake quant à lui me semble plus simple d'utilisation, mais là je n'ai pas trouvé comment lui dire de prendre en compte des fichiers en-tête situé dans moins lointain dossier...

bref
je suis perdu,
je vois pas comment m'en sortir,
je manque d'expérience,
je demande votre aide...

[dourouc05]

Salut,

ce problème ma semblé résolu quand j'ai découvert autotools. Problème les tuto que j'ai trouvé disent d'employer autoscan et de renommer le fichier de sortie configure.scan en configure.ac... et bien j'ai des erreurs lorsque je tape make...

Les fichiers configure.ac ne sont pas encore prêts à être utilisés avec sh : il faut encore lancer dessus aclocal, autoconf et automake.



À part ça, tu peux opter pour une autre solution, pour générer tes makefiles : un outil comme qmake peut te les fournir. Il est prévu pour Qt, mais il n'utilisera aucun des outils (rcc, moc...) s'ils ne sont pas nécessaires. En le lançant dans un répertoire, il va te générer tes makefiles. Si les paramètres par défaut te suffisent, pas besoin de sortir une plus gross artillerie.

En fait, pourquoi veux-tu utiliser les scripts configure ? Il est censé générer des makefiles et d'autres fichiers d'en-tête pour adapter un logiciel ou une librairie à une configuration particulière. Quand il n'y en a pas besoin, on distribue directement un Makefile.

[aoyou]

CMake quant à lui me semble plus simple d'utilisation, mais là je n'ai pas trouvé comment lui dire de prendre en compte des fichiers en-tête situé dans moins lointain dossier...

Tu dois utiliser la macro INCLUDE_DIRECTORIES.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
PROJECT (MonProjet)
 
INCLUDE_DIRECTORIES (MonDossier)
 
ADD_EXECUTABLE (MonExe
  MonSource1.cpp
  MonSource2.cpp
)
 
TARGET_LINK_LIBRARIES (MonExe MaLibrairie)

Si les entêtes que tu cherches sont ceux d'une librairie plutôt connue, il y a de fortes chances que quelqu'un ait écrit un module CMake pour le trouver. L'emplacement des entêtes est alors paramétrable via l'interface de CMake. Cela donnerait quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
PROJECT (MonProjet)
 
FIND_PACKAGE (MaLibrairie REQUIRED)
 
INCLUDE_DIRECTORIES (${MaLibrairie_INCLUDE_DIRS})
 
ADD_EXECUTABLE (MonExe
  MonSource1.cpp
  MonSource2.cpp
)
 
TARGET_LINK_LIBRARIES (MonExe ${MaLibrairie_LIBRARIES})

Je t'invite à lire l'initiation de Developpez.com.
http://florian-goujeon.developpez.co...ke/initiation/

ce problème ma semblé résolu quand j'ai découvert autotools.

Je travaillais avant avec les autotools mais j'ai très vite laissé tombé quand j'ai découvert CMake. Les autotools étaient beaucoup trop compliqués à utiliser (vive sh et m4 :-( ), limités aux Makefiles alors que CMake dispose d'un langage très intuitif et permet de générer des Makefiles mais aussi des projets pour des IDEs.

[TocTocKiéLà?]

merci de ta réponse,
j'arrive à compiler comme je veux maintenant avec CMake. Par contre j'ai une question, si je mets :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
(...)
LINK_DIRECTORIES(../lib)
(...)
target_link_libraries(
	toto
	libtest.so
)

je compile bien en dynamique ? si oui et sachant que ma bibliothèque se trouve dans le dossier /home/user/toto/lib, pourquoi quand je renomme le dossier lib par bil je peux exécuter mon programme ?

edit ::
en fait il semblerait que la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LINK_DIRECTORIES(../lib)

est ignoré, car j'arrive à faire (après un make clean) un cmake suivi d'une compilation sans accro. Donc qu'il utilise la librairie que j'ai dans /usr/lib/local, ce que je ne veux pas!

[aoyou]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

target_link_libraries(toto ../lib/libtest.so)

Pour les raisons que tu évoques, il est recommandé de passer le chemin complet (un peu comme dans Visual Studio finalement).

Je suis un peu surpris par le fait qu'il semble ignorer ta commande LINK_DIRECTORIES. Pour vérifier la librairie utilisée par un exécutable, un petit coup de ldd.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ldd MonExe

Pour information, CMake utilise le rpath à la compilation. L'exécutable retient le chemin des librairies dynamiques qu'il utilise. A l'installation, cette information est supprimée de l'exécutable.

EDIT
Au passage, petite question mais je ne pense pas que ce soit le cas, est-ce que libtest est une librairie de ton projet ? Tu sembles indiquer qu'elle vient d'un projet externe.

[TocTocKiéLà?]

Au passage, petite question mais je ne pense pas que ce soit le cas, est-ce que libtest est une librairie de ton projet ? Tu sembles indiquer qu'elle vient d'un projet externe.

Il s'agit des bibliothèques Ogre3D et OIS.

j'ai fait un test, j'ai renommé les bibliothèques respectivement libAffichage.so et libClavierSouris.so (ceux de mon répertoire lib), puis j'ai mis à jour le CMakeLists.txt avec cette nouvelle nomination. J'ai effacé toute trace de makefiles et des fichiers générés par cmake. Une fois compilé j'ai utilisé la commande ldd comme tu me l'as proposé (un type de commande que je cherchais depuis longtemps, merci) et là je vois que le binaire pointe sur les bibliothèques Ogre et OIS installées dans /usr/local/lib!

Visiblement il y a quelque chose qui m'échape...

pour expliquation, j'utilise actuellement un linux 32bit mais j'aimerais passer sous 64bit, par contre je devrais compiler en 32bits sous mon environnement 64bits. Je sais que ça n'a rien à voir, mais c'est pour expliquer pourquoi j'essai de forcer mon programme à utiliser les bibliothèques situées dans un repertoire lib que j'ai choisi.

[zul]

Si il n'y a pas d'information dans le binaire sur où sont situés les librairies (via rpath donc), le linker dynamique cherche dans les chemins contenus dans $LD_LIBRARY_PATH l'emplacement possible des bibliothèques. Si tu n'a pas renseigné cette variable, il doit chercher dans les chemins par défault tel que /usr/lib:/usr/local/lib etc

Pour résoudre ton problème, tu dois donc éditer cette variable d'environnement pour pointer en premier lieu vers tes librairies installées en local.

Par curiosité, pourquoi installer un système 64bits pour compiler en 32bits derrière ?

[aoyou]

Je ne suis pas tout dans tes essais... mais bon comme le propose zul, joue avec le LD_LIBRARY_PATH.

[TocTocKiéLà?]

Par curiosité, pourquoi installer un système 64bits pour compiler en 32bits derrière ?

Pour trois raisons :
1) parce que j'ai des ordinateurs équipés de proc 64bits.

2) compiler en 32bits pour un maximum de compabilité avec les ordinateurs où installer mon programme, qui eux ne sont pas forcément en 64bits.

3) j'ai par le passé, eu du mal à compiler (voir incapable...) certaines bibliothèques écrites à la bases pour du 32bits, j'étais donc revenus en 32bits. Bon je me rappelle plus lesquelles...

par contre pour rpath, je n'arrive pas à l'utiliser avec cmake, je ne comprends pas la doc de cmake à ce sujet.

Si vous avez un exemple, je suis preneur...

[TocTocKiéLà?]

bien, j'ai avancé à l'aide de ce lien :
http://www.cmake.org/Wiki/CMake_RPATH_handling

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET(CMAKE_INSTALL_RPATH "/home/user/toto/lib")

me permet de définir un chemin "prioritaire" pour la recherche de bilbiothèque au moment de l'exécution du binaire.

Par contre ça été la galère pour trouver le bon chemin relatif... je rappel mon arborescence :

/home/user/toto
/home/user/toto/bin

toto (fichier binaire)

/home/user/toto/src

main.cpp

/home/user/toto/lib

libtest.so

j'ai un CMakeLists.txt dans /home/user/toto "la racine de mon projet" contenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
cmake_minimum_required(VERSION 2.6)
PROJECT(toto)
ADD_SUBDIRECTORY(src)

et un CMakeLists.txt dans /home/user/toto/src contenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
 
# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 
 
# the RPATH to be used when installing
SET(CMAKE_INSTALL_RPATH "lib")
 
# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
 
 
LINK_DIRECTORIES(../lib)
 
LINK_LIBRARIES(test)
 
SET(main main.cpp)
ADD_EXECUTABLE(toto ${main})
 
 
set_target_properties(
	toto
	PROPERTIES 
	RUNTIME_OUTPUT_DIRECTORY ../bin
)

comme vous pouvez le constater j'ai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET(CMAKE_INSTALL_RPATH "lib")

et non pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET(CMAKE_INSTALL_RPATH "../lib")

ce que j'explique par le fait que je lance cmake et make depuis le dossier /home/user/toto alors que je pensais que le lien dans le CMakeLists.txt été relatif au dossier (et j'y ai passé de temps avant de comprendre...) le contenant comme par exemple pour la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LINK_DIRECTORIES(../lib)

J'en conclu que les commandes SET() devraient plutôt être inscrites dans le CMakeLists.txt contenu dans le dossier toto.

Qu'en pensez-vous, remarque, curiosité, critique ?

[aoyou]

Personnellement, je n'utilise pas le rpath à l'installation. L'exécutable est alors figé avec un chemin en dur et il n'est plus possible de déplacer la librairie ou l'exécutable, mais cela reste à vérifier. A mettre en relation avec les paquets relogeables.

Par contre, je trouve le rpath très pratique pour exécuter des tests unitaires dans l'arbre de compilation. Inutile de se soucier du lancement de l'exécutable de test, il est assuré d'être lancé avec les bonnes librairies. Sous Windows, il faut placer DLLs et exécutables dans le même répertoire pour être sûr que les exécutables se lancent avec les bonnes DLLs.

Tu as essayé la variable LD_LIBRARY_PATH ? Ca me paraît beaucoup moins contraignant que le rpath fixé à l'installation.

[TocTocKiéLà?]

j'aurai effectivement pu me passer de la commande rpath à l'installation et l'utiliser à l'exécution, mais c'est parce que j'avais temporairement déplacer la librairie libtest.so du dossier /usr/local/lib donc l'installation aurait échouée.

pour la commande que tu me proposes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LD_LIBRARY_PATH

si je ne dis pas de bétise - il faudrait que je configurer tous les ordinateurs sur lesquels j'aimerais employer mon programme non ?

mon objectif étant de le diffuser, j'aimerais un binaire et toutes les bibliothèques dans un fichier compressé afin de facilité l'installation et la supression.

je m'y prends peut-etre mal ?

[aoyou]

mon objectif étant de le diffuser, j'aimerais un binaire et toutes les bibliothèques dans un fichier compressé afin de facilité l'installation et la supression.

C'est ce qu'on appelle un paquetage. CMake permet de générer des RPMs et des paquets Debian. De manière plus simple, il permet aussi de générer des scripts d'installation. Tu devrais t'y intéresser si tu veux diffuser ton programme.

Pour ce qui est du LD_LIBRARY_PATH, tu peux écrire un petit script sh qui s'assure de positionner le bon LD_LIBRARY_PATH avant de lancer l'exécutable. Bon, d'accord ce n'est pas l'exécutable qui est directement lancé mais bon ça peut passer.

J'aurai effectivement pu me passer de la commande rpath à l'installation et l'utiliser à l'exécution

Euh... je n'ai pas tout compris. Tu parles de l'exécution une fois installé. Cela ne change pas grand chose. Une fois installé, l'exécutable est marquée avec le chemin vers la librairie en dur. Je ne sais pas ce qui se passe quand on déplace la librairie dans ce cas. Est-ce que le système se débrouille quant même ?

Est-ce si grave le mélange entre les librairies 32 et 64 bits ? Est-ce que le système ne se débrouille pas pour choisir la bonne librairie dynamique ?

Si ça peut t'aider...
http://www.redhat.com/magazine/009ju...ures/multilib/

[TocTocKiéLà?]

Euh... je n'ai pas tout compris. Tu parles de l'exécution une fois installé. Cela ne change pas grand chose. Une fois installé, l'exécutable est marquée avec le chemin vers la librairie en dur.

En fait ce que je voulais dire c'est que on peut définir un rpath qui peut être utilisé pendant l'installation (<=> compilation) ET/OU peut être utilisé pendant l'exécution, est-ce que je suis clair ? car il est tard...

Je ne sais pas ce qui se passe quand on déplace la librairie dans ce cas. Est-ce que le système se débrouille quant même ?

pour faire cours, oui.
Dans l'ordre il va d'abord chercher la bibliothèque dans le dossier indiqué par rpath, s'il ne la trouve pas il ira chercher dans les dossiers du système de fichiers indiqués comme contenant des bibliothèques.

Est-ce si grave le mélange entre les librairies 32 et 64 bits ? Est-ce que le système ne se débrouille pas pour choisir la bonne librairie dynamique ?

On peut utiliser des bibliothèques 32bits sur un système 64bits, je l'ai déjà fait; l'exemple le plus commun est la bibliothèque d'adobe pour lire les flashs, la version 64bits n'existait pas il y a quelques mois, fallait se rabattre sur la 32bits. Aujourd'hui je ne sais pas si elle existe, je verrai ça assez prochainement quand j'installerai à nouveau mes linux en 64bits...
Par contre je ne pourrais plus dire comment j'avais fait (j'avais trouver la solution sur un forum ubuntu)...
j'espère avoir été à peu près clair, car là je suis claqué... j'irai voir ton lien demain.

[aoyou]

On peut utiliser des bibliothèques 32bits sur un système 64bits

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

[TocTocKiéLà?]

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

je n'ai jamais fait de tests mais j'avais pu lire sur un autre forum que la réponse est non.

[jabbounet]

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

ça va dépendre de l'archi de ton OS, s'ils ont fait un effort la dessus ou pas....

http://www-03.ibm.com/systems/power/...ons/index.html

[TocTocKiéLà?]

merci pour vos divers infos, comme on est entrain de déborder du sujet initial, je le mets en résolu, puisque aujourd'hui je travail sans IDE, le problème est réglé

merci à vous