Comment compiler en c++
Fermé
kamdjou
-
Modifié par mamiemando le 10/12/2011 à 12:47
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 10 déc. 2011 à 12:46
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 10 déc. 2011 à 12:46
A voir également:
- Comment compiler en c++
- Compiler plusieurs pdf - Guide
- Inno setup compiler - Télécharger - Édition & Programmation
- Compiler plusieurs fichiers excel - Guide
- Download code blocks with compiler - Télécharger - Langages
- Comment faire une compilation de musique - Forum Audio
1 réponse
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
10 déc. 2011 à 12:46
10 déc. 2011 à 12:46
Version brève
De base il faut juste installer g++. Par exemple sous Debian (qui est basée sur le gestionnaire de paquets apt, http://www.mistra.fr/tutoriel-linux-apt.html) :
Ensuite il suffit d'écrire un fichier ".cpp" à l'aide de n'importe quel éditeur texte (gedit, kwrite, vim, emacs, ...) et le compiler (avec g++).
Exemple : /home/toto/hello.cpp
Pour le compiler :
Pour le lancer :
Quelques rappels sur la compilation en C/C++
Souvent un projet est décomposé en plusieurs fichiers sources (.cpp, .hpp...) et il serait fastidieux d'appeler explicitement g++ pour chaque fichier ".cpp".
Ainsi en pratique, il faut au préalable installer un compilateur (généralement g++) et make via le gestionnaire de paquets. Tu peux aussi carrément installer un environnement de développement (anjuta, kdevelop...).
Note : un environnement de développement (IDE) ne fait que rassembler les outils dont nous avons parler (un éditeur texte, g++ et make) dans une interface graphique (ainsi que quelques autres dont nous n'avons pas parlé, comme gdb le debugger etc...).
Exemple :
L'utilitaire 'make' permet de lancer la compilation "scriptée" dans le fichier Makefile généralement livré avec les sources. Concrètement, make va :
1) compiler chaque chaque fichier ".cpp" (ce qui va produire autant de fichiers ".o") en appelant g++,
2) les linker (toujours grâce à g++ en vue de produire un binaire finale, qui peut être
a) un exécutable (".exe" sous windows, pas d'extension sous linux)
b) une librairie dynamtique (".dll" sous windows, ".so" sous linux)
c) une libraire statique (".lib" sous windows, ".a" sous linux)
d) un module (concept qui n'existe pas sous windows, ".ko" sous linux)
A priori tu es plus probablement dans le cas (a) ou (b).
Lors de l'étape (2) tu vois qu'il y une phase de linkage. C'est l'étape où l'on lie un programme aux librairies qu'il utilise. Par exemple si j'écris une application graphique pour KDE, je vais utiliser la librairie Qt et donc mon programme sera lié avec. Évidemment pour que ce soit réalisable, il faut que cette librairie soit installée. Concrètement, pour lier un programme à une librairie il faut
- les headers associés à cette librairie (.h, .hpp)
- la librairie en elle-même (.a ou .so)
Dans ce qui suit je fais l'amalgame entre C et C++ car ce sont les mêmes concepts, je parlerai indifféremment de ".c", ".cpp" ou de ".h", ".hpp".
Tu peux t'amuser avec ldd avoir que les commandes ou les programmes que tu utilises sous linux sont liés à plein de librairies.
Exemple : la commande 'ls'
On voit par exemple ici que ce programme est lié à libc, libpthread etc... Cela suppose que quelqu'un avait - les sources de "ls" (.h, .c)
- pour chacune des librairies (dynamique) leurs .h et leur .so
(je fais abstraction des librairies statiques qui n'apparîtront jamais dans ldd).
Dans ton cas c'est la même chose : tes sources reposent sans doute sur d'autres librairies, qu'il va falloir au préalable installer. Note que quand on lance un programme (par exemple "ls"), on n'a besoin que de ses ".so". Ainsi un utilisateur n'a pas besoin des ".h" qui ont servi à lier le programme à une librairie donnée. C'est la raison pour laquelle sous linux on trouve souvent pour une librairie donnée deux paquets :
- un paquet qui ne contient que le ".so" (exemple : libpcre3)
- un paquet qui contient le ".so" et les ".h" (paquet de développement) (exemple : libpcre3-dev)
Note : sous Debian et les distributions qui en dérivent (Ubuntu...) les paquets de développement sont généralement suffixés "...-dev". Pour les distributions qui dérivent de Redhat (Fedora, Mandriva...), les paquets de développement sont généralement suffixés "...-devel". Dans tous deux cas ces paquets sont préfixés "lib..."
Compiler un exemple plus compliqué
Tu l'auras compris pour compiler un programme plus compliqué, un makefile sera généralement livré et il faudra s'assurer au préalable que toutes les librairies nécessaires à la compilation sont présentes. C'est la raison pour laquelle sous linux, un script "configure" est également là pour vérifier que tout est bon. Le cas échéant il faut installer le paquet de développement correspondant.
Supposons que je veuille compiler un programme livré avec un makefile et un configure et que je l'ai stocké dans /home/toto/superprogramme :
Si par exemple la compilation requiert "libpcre" (par exemple) et que je ne l'ai pas installée, alors j'aurai un message d'erreur à ce stade. Il faut donc partir à sa recherche (par exemple avec apt-cache sous Debian) pour trouver le paquet qui va me la fournir (dans cet exemple ce serait libpcre3-dev) et l'installer
Il faut répéter cette méthodologie jusqu'à ce que ./configure arrive à terme avec succès (dans ce cas, toutes les librairies requises seront correctement installées). On peut alors démarrer la compilation :
Bonne chance
De base il faut juste installer g++. Par exemple sous Debian (qui est basée sur le gestionnaire de paquets apt, http://www.mistra.fr/tutoriel-linux-apt.html) :
aptitude update aptitude safe-upgrade aptitude install g++
Ensuite il suffit d'écrire un fichier ".cpp" à l'aide de n'importe quel éditeur texte (gedit, kwrite, vim, emacs, ...) et le compiler (avec g++).
Exemple : /home/toto/hello.cpp
#include <iostream>
int main(){
std::cout << "hello !" << std::endl;
return 0;
}
Pour le compiler :
cd /home/toto g++ -W -Wall -o hello hello.cpp
Pour le lancer :
./hello
Quelques rappels sur la compilation en C/C++
Souvent un projet est décomposé en plusieurs fichiers sources (.cpp, .hpp...) et il serait fastidieux d'appeler explicitement g++ pour chaque fichier ".cpp".
Ainsi en pratique, il faut au préalable installer un compilateur (généralement g++) et make via le gestionnaire de paquets. Tu peux aussi carrément installer un environnement de développement (anjuta, kdevelop...).
Note : un environnement de développement (IDE) ne fait que rassembler les outils dont nous avons parler (un éditeur texte, g++ et make) dans une interface graphique (ainsi que quelques autres dont nous n'avons pas parlé, comme gdb le debugger etc...).
Exemple :
aptitude install g++ make
L'utilitaire 'make' permet de lancer la compilation "scriptée" dans le fichier Makefile généralement livré avec les sources. Concrètement, make va :
1) compiler chaque chaque fichier ".cpp" (ce qui va produire autant de fichiers ".o") en appelant g++,
2) les linker (toujours grâce à g++ en vue de produire un binaire finale, qui peut être
a) un exécutable (".exe" sous windows, pas d'extension sous linux)
b) une librairie dynamtique (".dll" sous windows, ".so" sous linux)
c) une libraire statique (".lib" sous windows, ".a" sous linux)
d) un module (concept qui n'existe pas sous windows, ".ko" sous linux)
A priori tu es plus probablement dans le cas (a) ou (b).
Lors de l'étape (2) tu vois qu'il y une phase de linkage. C'est l'étape où l'on lie un programme aux librairies qu'il utilise. Par exemple si j'écris une application graphique pour KDE, je vais utiliser la librairie Qt et donc mon programme sera lié avec. Évidemment pour que ce soit réalisable, il faut que cette librairie soit installée. Concrètement, pour lier un programme à une librairie il faut
- les headers associés à cette librairie (.h, .hpp)
- la librairie en elle-même (.a ou .so)
Dans ce qui suit je fais l'amalgame entre C et C++ car ce sont les mêmes concepts, je parlerai indifféremment de ".c", ".cpp" ou de ".h", ".hpp".
Tu peux t'amuser avec ldd avoir que les commandes ou les programmes que tu utilises sous linux sont liés à plein de librairies.
Exemple : la commande 'ls'
(mando@aldur) (~) $ ldd $(which ls)
linux-vdso.so.1 => (0x00007fff2d0b4000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f1287acc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f12878c4000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f12876bb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1287337000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1287133000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1287d04000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1286f16000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f1286d12000)
On voit par exemple ici que ce programme est lié à libc, libpthread etc... Cela suppose que quelqu'un avait - les sources de "ls" (.h, .c)
- pour chacune des librairies (dynamique) leurs .h et leur .so
(je fais abstraction des librairies statiques qui n'apparîtront jamais dans ldd).
Dans ton cas c'est la même chose : tes sources reposent sans doute sur d'autres librairies, qu'il va falloir au préalable installer. Note que quand on lance un programme (par exemple "ls"), on n'a besoin que de ses ".so". Ainsi un utilisateur n'a pas besoin des ".h" qui ont servi à lier le programme à une librairie donnée. C'est la raison pour laquelle sous linux on trouve souvent pour une librairie donnée deux paquets :
- un paquet qui ne contient que le ".so" (exemple : libpcre3)
- un paquet qui contient le ".so" et les ".h" (paquet de développement) (exemple : libpcre3-dev)
Note : sous Debian et les distributions qui en dérivent (Ubuntu...) les paquets de développement sont généralement suffixés "...-dev". Pour les distributions qui dérivent de Redhat (Fedora, Mandriva...), les paquets de développement sont généralement suffixés "...-devel". Dans tous deux cas ces paquets sont préfixés "lib..."
Compiler un exemple plus compliqué
Tu l'auras compris pour compiler un programme plus compliqué, un makefile sera généralement livré et il faudra s'assurer au préalable que toutes les librairies nécessaires à la compilation sont présentes. C'est la raison pour laquelle sous linux, un script "configure" est également là pour vérifier que tout est bon. Le cas échéant il faut installer le paquet de développement correspondant.
Supposons que je veuille compiler un programme livré avec un makefile et un configure et que je l'ai stocké dans /home/toto/superprogramme :
cd /home/toto/superprogramme ./configure
Si par exemple la compilation requiert "libpcre" (par exemple) et que je ne l'ai pas installée, alors j'aurai un message d'erreur à ce stade. Il faut donc partir à sa recherche (par exemple avec apt-cache sous Debian) pour trouver le paquet qui va me la fournir (dans cet exemple ce serait libpcre3-dev) et l'installer
aptitude install libpcre3-dev ./configure
Il faut répéter cette méthodologie jusqu'à ce que ./configure arrive à terme avec succès (dans ce cas, toutes les librairies requises seront correctement installées). On peut alors démarrer la compilation :
make
Bonne chance
