Lancer un programme

Fermé
Babas - 31 janv. 2012 à 20:31
mamiemando Messages postés 33574 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mars 2025 - 3 févr. 2012 à 11:03
Bonjour,
j'aurais besoin de faire tourner un programme sur mon Linux (j'utilise une virtualisation, mais je ne pense pas que cela soit important dans ce cas), j'ai pour cela un fichier makefile, un fichier run et un fichier codé en c. J'ai déjà essayé diverses méthodes trouvées sur le net, mais cela ne marchait jamais. Je voudrais donc savoir quelle est la manière de pouvoir le faire tourner. Par contre, je suis un débutant sur Linux, et j'ai juste quelques notions, apparemment insuffisantes (dans le genre parcours de dossiers tout ça, mais ce n'est pas le plus important...).
Merci d'avance.
Babas

5 réponses

mamiemando Messages postés 33574 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mars 2025 7 833
31 janv. 2012 à 21:04
Si ton programme est écrit en c, il faut le compiler pour produire un exécutable. On peut dans un premier jet installer tout ce qui va forcément servir comme gcc et make. Par exemple sous Ubuntu :

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install make gcc


1) Cela pré-suppose évidemment que le paquet make a été installé au préalable, ainsi que le nécessaire pour compiler (gcc, make, mais aussi les éventuelles librairies utilisées par le programme etc...). Généralement cette étape de vérification est réalisée grâce au script "configure" présent dans le répertoire de sources. Note que ce fichier n'existe pas forcément, dans ce cas passe directement à l'étape 2 (en priant pour que tout soit installé)

cd /le/repertoire/contenant/tes/sources
./configure


2) Ceci est typiquement réalisé grâce à gcc, qui est appelé le plus souvent au travers d'un makefile. Généralement pour compiler, il suffit de se placer dans le répertoire du makefile et de taper :

make


Si on te dit qu'il manque des headers, c'est probablement que tu as oublié d'installer une librairie (et dont le nom de paquet commence par lib et fini par dev. Exemple : libpcre3-dev). Encore une fois, une librairie s'installe généralement tout simplement via ton gestionnaire de paquets (apt-get dans le cas d'Ubuntu, Debian etc... Précise nous ta distribution si tu as des difficultés à installer des paquets).

3) Une fois la compilation achevée, tu peux lancer ton exécutable. Supposons que son chemin soit /home/mando/mon/programme. Dans un premier temps lis ceci où j'explique le rôle de la variable d'environnement PATH (et comment l'afficher) :
https://forums.commentcamarche.net/forum/affich-24306514-comment-lancer-hotpotatoes-java#11

4) Tu l'auras compris, /home/mando/mon n'est pas dans PATH, il faut donc se placer dans ce répertoire (ou ajouter ce répertoire à PATH). Ainsi je devrais taper :

cd /home/mando/mon
./programme


... ou encore :

/home/mando/mon/programme


Bonne chance
1
Merci beaucoup déjà pour m'accorder un peu de ton aide!
J'ai déjà tout d'installer pour ce qui est gcc et tout le reste, et je travaille sous Ubuntu.
En fait, à l'aide du peu de notions que j'avais et en bidouillant un peu, j'avais bien compilé et j'étais arrivé à l'étape 3. Je ne sais pas si c'est important, mais quand j'ai compilé le programme dans le terminal, il m'affiche:

rm -f *.o *.gp data/* nls.jpg nls.eps *.dat *.txt 


Alors je ne sais absolument pas ce que ça représente ! Peut être, cela veut-il dire qu'il a compilé?
En supposant que c'est le cas (et je pense que ça l'est), j'ai maintenant un exécutable dans mon dossier où il y avait mes trois autres fichiers. Mais alors, je n'ai pas très bien compris ce qu'était PATH... Il me semble que c'est une variable, mais je n'ai pas bien compris comment l'utiliser (j'ai essayé de regarder ton lien, mais c'est un peu (beaucoup) flou). En fait, PATH c'est une variable ou un répertoire? (les deux peut-être?). Et quelle est la commande pour ajouter un répertoire à PATH? (je n'ai pas très bine compris les lignes de "terminal" que tu as mises)

Encore un grand merci pour ton aide, et le temps que tu prends.
Babas
0
mamiemando Messages postés 33574 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mars 2025 7 833
1 févr. 2012 à 20:15
rm -f *.o *.gp data/* nls.jpg nls.eps *.dat *.txt

Tu peux retrouver la signification de la commande rm (et plus généralement de n'importe quelle commande linux) à l'aide du man :
http://www.mistra.fr/tutoriels-linux-mode-texte/tutoriel-linux-man.html

man rm


Cette commande sert simplement à supprimer des fichiers (tous ceux qui finissent par ".o", ".gp" etc...). A priori ça n'a pas d'impact sur la compilation.

Peut être, cela veut-il dire qu'il a compilé?

Non s'il avait compilé tu verrais une ligne de linkage (avec gcc et quelque part dans les méandres de la ligne, le fichier que tu as compilé). Je pense que tu devrais jeter un oeil ici pour avoir les bases qui te manquent :
http://www.mistra.fr/tutoriel-linux-compiler.html

En supposant que c'est le cas (et je pense que ça l'est), j'ai maintenant un exécutable dans mon dossier où il y avait mes trois autres fichiers.

Je ne sais pas, est ce que ces sources sont disponibles quelque part. Je ne sais même pas ce que tu compiles donc c'est un peu difficile de répondre :-)

Mais alors, je n'ai pas très bien compris ce qu'était PATH... Il me semble que c'est une variable, mais je n'ai pas bien compris comment l'utiliser (j'ai essayé de regarder ton lien, mais c'est un peu (beaucoup) flou). En fait, PATH c'est une variable ou un répertoire? (les deux peut-être?)

PATH est (de même que sous windows) une variable d'environnement. C'est une valeur en mémoire qui stocke une information qui influe sur le comportement de ton shell (le truc dans lequel tu tapes des commandes).

En temps normal sous linux, il faut taper explicitement le chemin d'un exécutable pour le lancer (par exemple, /bin/ls pour lister les fichiers du répertoires courant). En fait, la plupart des commandes que tu tapes sont des exécutables cachés quelque part dans l'arborescence linux :
http://www.mistra.fr/tutoriel-linux-fhs.html

Il serait fastidieux de taper /bin/ls ou /usr/bin/gcc à chaque fois qu'on en a besoin (et en plus ça forcerait à se souvenir du répertoire dans lequel se trouve l'exécutable !). C'est la que la variable PATH intervient. Quand tu lances une commande (qui n'est pas une built-in shell, bref passons), par exemple :

ls


... ton shell se dit "mmmh où est donc cet exécutable ?". Il regarde la valeur de PATH qu'on peut afficher comme suit :

(mando@aldur) (~) $ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


Avec ce PATH, il regarde d'abord dans /usr/local/bin, il ne trouve pas, il regarde dans /usr/bin, il ne trouve pas, donc il regarde dans /bin et ah ! il y est. Donc "ls" est interprété comme étant en réalité /bin/ls.

(mando@aldur) (~) $ which ls
/bin/ls


Dans ton cas, l'exécutable que tu crées n'est pas dans un répertoire listé dans PATH, donc pour le lancer il faut :
- soit donner le chemin complet : /home/mando/programme
- soit déplacer cet exécutable dans un répertoire référencé dans le PATH (sachant que seul root peut le faire)
- soit ajouter le répertoire dans lequel il se trouve dans ton PATH

export PATH="/home/mando:$PATH"


Personnellement je pense que la première approche est la plus simple...

Quelques compléments sur les variables d'environnement shell (dont PATH). Une variable d'environnement à la même durée de vie que le shell, et sa portée est limitée à ce shell. En bon français, cela veut dire que si tu la modifies, cette modification ne sera prise en compte que dans ce shell. Si tu fermes le shell et que tu en ouvres un nouveau, le PATH sera réinitialisé. On peut personnaliser cette variable d'environnement mais bon, on va dire que je ne pense pas que ce soit important d'en parler dans ton cas.
0
Excuse-moi si je passe complètement à autre chose :-s
Alors, pour être sûr de ne rien avoir oublié d'installer ou quoi (et rencontrant quelques problèmes avec ma machine), j'ai tout recommencé (installation des paquets et toute la ribambelle de trucs à faire) sur un tout nouveau Linux, fraîchement installé et tout. Je suis donc désormais sur antiX.
J'ai recommencé toute la compilation et, ô joie, en "lançant" le make, il m'affiche:
gcc -Wall -O3 nls.c -o nls -lm

(+ le rm et tout ce qui suit)
Je pense donc que c'est bon, ça va marcher, et lance donc un make install, mais:
make: *** No rule to make target 'install'.  Stop.

Grrrr...je l'aurais un jour...
Je suis vraiment désolé si tu vas me répéter ce que tu disais plus haut, mais j'avoue être un peu perdu.
Au fait, comme fichiers, j'ai : nls.c (mon fichier source), makefile, run, nls (l'exécutable). Et rien de plus, mais quand tu me dis que tu ne sais pas ce que je compile, comment je pourrais t'aider à y voir plus clair?
Encore merci pour tout, ça ne doit pas être facile de répéter 5000 fois les mêmes choses à tous les boulets comme moi. :-/
0
Oups...je pense m'être fourvoyé...Le make install n'est employé que pour les applications, non?
Ensuite, la personne qui m'a envoyé ce programme, m'a donné comme consigne de taper:
chmod u+x run

puis
run

Je sais que chmod sert à donner des droits d'utilisation, mais ai-ke besoin de faire ceci une fois le programme compilé?
Babas
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
mamiemando Messages postés 33574 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mars 2025 7 833
Modifié par mamiemando le 3/02/2012 à 11:04
N'oublie pas que si tu poses des questions sur un sujet qui n'a rien à voir avec le problème initial, il vaut mieux ouvrir un autre fil de discussion pour des raisons de lisibilité.

Pour que "make install" ait une chance de marcher (et indépendemment de ce que tu compiles) il faut qu'il y ait une cible "install" dans le fichier Makefile. Il est d'usage d'avoir une cible all, install, uninstall, clean etc... dans un Makefile, mais rien ne t'y oblige.

Normalement quand tu compiles un programme, celui-ci a directement des droits en exécution, donc tu n'as pas spécialement de chmod à faire. Mais comme je t'ai dit plus haut, écrire :

run


n'a pas de sens, à moins qu'un exécutable run soit présent dans l'un des répertoire énumérés dans PATH. Si ce n'est pas le cas, il faut donner le chemin explicitement de l'exécutable :

- par exemple si "run" est dans /home/toto (ou n'importe quel répertoire en dehors du PATH) :

/home/toto/run


- si ton shell est placé dans /home/toto :

./run


Bonne chance
0