Salut,
Bon, pour commencer, on va essayer de te permettre de comprendre comment fonctionne un compilateur. Je crois que cela s'avère nécessaire.
Quand on parle de "compiler" une application, on fait généralement un abus de langage, car nous devrions dire que nous faisons passer du code par "une succession d'outils" bien spécifiques, à savoir:
- le préprocesseur, qui va -- je vais simplifier -- s'occuper de toutes les commandes commençant par le symbole # (dont l'instruction #include <nom_de_fichier>, dont le but est de remplacer cette instruction par... le contenu du fichier nom_de_fichier)
- le compilateur en lui-même dont le but est de "convertir" le code d'un fichier d'implémentation (les fichiers portant l'extension .cpp, par exemple) en une succession d'instructions qui seront compréhensibles par le processeur et
- l'éditeur de liens d'aller chercher dans les "bibliothèques externes" le code binaire (celui qui est compréhensible par le processeur) des fonctions que l'on a pas codées, mais que l'on utilise dans notre code, afin de générer l'exécutable final.
(je donne une version très simplifiée ici, car c'est parfois un peu plus complexe que cela )
L'idée générale, c'est que le préprocesseur et l'éditeur de liens ne vont pas commencer à parcourir l'ensemble du disque dur pour trouver les fichiers qui les intéressent : ils vont se "limiter" à ... un "petit" nombre de dossiers bien spécifiques.
Certains de ces dossiers sont "utilisés par défaut", c'est à dire que tu n'as pas à les indiquer de manière systématique pour que l'éditeur de lien ou le préprocesseur aille voir dedans s'il n'y trouverait pas -- à tout hasard -- le fichier dont il a besoin.
Mais, évidemment, si le fichier dont le préprocesseur ou l'éditeur de liens n'est pas dans un de ces "dossiers utilisés par défaut", il faut lui indiquer qu'il doit "aller voir ailleurs", en lui indiquant, bien sur, où se trouve ce "ailleurs".
Autrement, il n'ira pas voir ailleurs de "sa propre initiative", et, comme il ne trouvera pas le fichier qui l'intéresse, il ne pourra faire qu'une seule chose : se plaindre de ne pas trouver le fichier et... arrêter le processus de compilation.
L'éditeur de liens est, d'ailleurs, encore plus stricte que le préprocesseur, car, outre le fait qu'il va aller chercher dans des dossiers bien spécifiques, il n'ira jamais voir dans "toutes les bibliothèques qu'il trouve" si, par le plus grand des hasard, il n'y trouverait pas le code binaire dont il a besoin.
Le préprocesseur est beaucoup plus souple à ce point de vue, car, si il trouve le fichier dont il a besoin dans un des dossiers dans lesquels il regarde, il sera content, et il copiera gentiment le contenu du fichier trouvé.
Quand tu utilise les options de compilation -L /cd/home/libc/Desktop/fftw-3.3.6-pl2/api -lfftw3 -lm, tu t'adresse à l'éditeur de liens (et uniquement à lui) en lui disant:
- -L /cd/home/libc/Desktop/fftw-3.3.6-pl2/api tu trouveras peut être une bibliothèque qui pourrait t'intéresser dans le dossier /cd/home/libc/Desktop/fftw-3.3.6-pl2/api
- -lfftw3 tu trouveras le code binaire de certaines fonctions qui t'intéressent dans la bibliothèque nommée libfftw3.a
- -lm tu trouveras le code binaire de certaines fonctions qui t'intéressent dans la bibliothèque nommée libm.a
Le tout, en espérant qu'il sera effectivement en mesure de trouver les bibliothèques nommées libfftw3.a et libm.a dans ... un des dossiers dans lesquels il ira chercher.
Pour le préprocesseur, on change simplement les options de compilation, mais le principe est le même.
Ainsi, si on veut lui dire qu'il doit aller voir du coté du dossier /truc/bidule/machinchose s'il ne trouverait pas par hasard un des fichiers d'en-tête qui l'intéresse, il faut le lui indiquer en utilisant l'option -I (c'est un i majuscule )
Mais ca ne sert à rien de lui donner le dossier dans lequel se trouve libfftw3.a. Le préprocesseur s'en fout pas mal des bibliothèques: Ce que lui veut, c'est pouvoir trouver les fichiers d'en-tête (typiquement, des fichiers dont l'extension sera .h, .hpp, .hxx ou quelques autres)
Ainsi, quand tu obtiens le message d'erreur sampling.cpp:9:19: fatal error: fftw3.h: No such file or directory, c'est... parce que le préprocesseur n'a pas été en mesure de trouver le fichier d'en-tête nommé fftw3.h. Pourquoi généralement parce qu'il n'a pas été chercher dans le dossier dans lequel se trouve ce fichier (plus rarement parce que le fichier n'existe purement et simplement pas).
Alors, comment résoudre ce problème en commençant par déterminer où se trouve ce foutu fichier. Il est surement "quelque part" dans les dossiers que tu trouves du coté de /cd/home/libc/Desktop/fftw-3.3.6-pl2, mais il y a vraiment très peu de chances pour qu'il soit dans le dossier api.
Personnellement, je ne serait pas surpris s'il se trouvait dans un dossier nommé ... include
Une fois que tu auras trouvé le fichier que le préprocesseur se plaint de ne pas trouver, tu pourras indiquer le chemin qui mène au dossier qui y mène sous une forme qui ressemblera sans doute à -I/cd/home/libc/Desktop/fftw-3.3.6-pl2/include, et "tout le monde sera content:
- le préprocesseur parce qu'il pourra trouver le fichier fftw3.h
- l'éditeur de liens parce qu'il pourra trouver la bibliothèque libfftw3.a
- et, le plus important : toi, parce que tu pourras obtenir ton exécutable
Partager