Archlinux.fr [Forums]

Bonjour !

J'essaie de me passer d'IDE pour apprendre à compiler en ligne de commande, mais c'est la galère.

J'ai un fichier "main.cpp", qui inclue un fichier "www.h" et donc le fichier "www.cpp" qui va avec.


La compilation de "main.cpp" seul fonctionne. Mais je ne peux pas linker le projet tant que "www.cpp" n'a pas aussi été compilé.

Sauf que quand je lance la compilation de "www.cpp", je me prends une erreur vu que mes classes sont déclarées dans "www.h", et que l'inclusion automatique ne se fait pas dans se sens là !

Alors que dois-je faire, quelqu'un a une idée pour me sauver la vie ? ^^

Salut,

sans voir le contenu de tes fichiers, ça va être dur de t'aider...
Mais tu devrais avoir :
- main.cpp : doit contenir la ligne '#include <www.h>'
- www.cpp : doit contenir la ligne '#include <www.h>'

Et d'après ce que j'ai horriblement compris de ton texte, main.cpp ne doit SURTOUT pas inclure www.cpp.

et tu compiles via : EDIT : grrrrrrrrr... l'éditeur me rajoute systématiquement http:// devant mes 'www'

C'est du code propriétaire, je n'ai pas le droit de le poster. (Pas taper, c'est pas moi qui l'ai voulu !)

Il faut juste comprendre que les classes utilisées dans "www.cpp" sont définies dans "www.h".

Alors donc les fichiers doivent effectuer une auto-inclusion ?
Pourquoi ? Je n'y aurais jamais pensé.

[edit : ah non, c'est une inclusion de sa propre entête, j'avais mal lu. (Mais alors ça va l'inclure lui-même aussi non ?)]

Le -o est une option, il permet d'indiquer le fichier de sortie souhaité. compilera main.cpp www.cpp et liera les 2 pour en faire un exécutable du nom de main

Auto-inclusion... c'est quoi ce terme ?
Je ne veux pas tout le code, juste les include.

Mais avec ce que j'ai t'ait dit plus les compléments de tuxce, tu ne devrais pas avoir de souci.

Et 'man' t'aidera à comprendre avant de recopier

D'accord, merci beaucoup pour vos réponses !


En fait mon problème vient peut-être d'ailleurs, parce que vos solutions sont déjà ce que j'applique et j'ai un tas d'erreur de compilation. Pourtant l'appli est déjà sortie, donc quelqu'un a déjà réussi à la compiler.

Je vais continuer à chercher.

Merci encore et bonne journée !

Sauf que la commande de Tuxce c'est bien pour les petits projets, pour les gros projets je conseil quand même la création de .o : gcc -c ton-fichier.c
Puis gcc f1.o f2.o -o executable
L'avantage c'est que l'on sépare très nettement la compilation du code objet du linkage, et donc c'est plus simple pour comprendre ou cela coince...

Ok ça compile maintenant. Je vous remercie de vous être penchés sur mon problème !

(En fait tous les fichiers ".cpp" se trouvaient en vrac dans un dossier, mais une bonne vingtaine d'entre eux étaient des backups ou d'anciennes version du code à exclure de la compilation.)



Sauf que... Ça ne link pas !

Je me prends des milliers de "indefined reference to" ne concernant que les fichiers sources. (Donc pas de problème avec les bibliothèques, à priori)
Voici le prototype du problème :


---------------------------------------------
Le linkeur renvoie quelque chose comme : In "Events.o" : Undefined reference to "Get_xml_content()"
Pourtant :

• Le fichier "XML.h" et son ".cpp" définissent/implémentent la fonction "Get_xml_content()" ;
• Le fichier "Events.cpp" ne contient aucun appel à la fonction "Get_xml_content()" ;
• Le fichier "Events.cpp" inclue le fichier "XML.h".

---------------------------------------------


Quelqu'un a déjà eu affaire à ce symptôme ?
Dans quel cas le linkeur peut-il bien inventer des références indéfinies alors que les fichiers ont correctement compilé ?
Est-ce qu'une librairie manquante peut provoquer un "effet boule de neige" en désactivant progressivement toutes les fonctions incomplètes ?

Voici la ligne de commande utilisée (Sous windows en VM, car le produit final est kro$oftien malheureusement) : PS : Il se passe la même chose en compilant et liant d'une traite l'application.

Je crains que sans voir le code source on ne soit d'aucune aide...
On ne peut faire que des suppositions à ce niveaux là...
Mais je pense voir le problème : Mélange entre C++ et C sans utilisation de extern C ?

Dans tous les cas, demander de l'aide ici n'est clairement pas une bonne idée, car au final c'est du code Windows qui est de plus propriétaire...

Il n'y a que des ".cpp" dans le projet.
Oui c'est vrai que tout compte fait, poster sur un forum linux les problèmes rencontrés en compilant du code propriétaire pour windows n'est pas l'idéal.

Mais c'est pour la bonne cause, je dois adapter le logiciel pour linux, alors j'essaie d'abord de le compiler avec Gcc sous windows.

J'aimerais bien aider mais sans le code... Tu peux toujours le faire par MP si tu ne veux pas faire du 100% public...
Comment tu compiles les fichiers cpp ? As tu bien activé l'affichage des warning avec -Wall voir en ajoutant aussi -Wextra ?

Van a écrit :(En fait tous les fichiers ".cpp" se trouvaient en vrac dans un dossier, mais une bonne vingtaine d'entre eux étaient des backups ou d'anciennes version du code à exclure de la compilation.)

Pour moi, il y a un problème d'ingénierie logicielle à ce niveau là... Les gestionnaires de version, ça n'est pas fait juste pour décorer.
Et puis pour un gros projet, il vaut mieux utiliser des outils comme cmake ou automake plutôt que de tout se taper à la main.

C'est quoi comme soft sinon?

@Rolinh 20 fichiers ce n'est pas beaucoup, mais le fait qu'il n'existe même pas de Makefile basique, ainsi que les différents points que tu as relevé laisse planer un doute sur la qualité et les compétences des personnes ayant écrit ceci...
De plus que Van ne sache pas corriger ceci tout seule me fait aussi un peu peur... désolé

Zut je suis démasqué... En effet j'avoue que le C++ n'est pas mon principal domaine de compétence.

En fait pour être plus clair : Je suis développeur Java et Php (accessoirement C sous IDE), et là on m'a refilé à titre exceptionnel un logiciel en C++ à adapter pour Linux. Mais il y a plus de 150 fichiers ".cpp" de quelques milliers de lignes chacun, et les développeurs précédents m'ont codé ça comme des [auto-censuré].

Évidemment ils le compilaient avec un IDE archi-krosoftien, du coup GCC n'aime pas du tout les énormités dans la syntaxe et quelques insertions asm non AT&T.



Bon allez c'est promis, j'arrête de me plaindre de la vie ici, c'est pas le bureau des pleurs.



Donc voici la ligne utilisée pour compiler (après avoir épuré le dossier "src" des ".cpp" obsolètes) :
Bon avant de procéder à ma lapidation en direct, il faut juste savoir qu'en retirant l'option "-fpermissive" j'obtiens une bonne dizaine de milliers d'erreurs...

Rassurez-moi, mes problèmes ne viennent pas de là ??



Je vais peut-être passer pour un guignol (au point où j'en suis...), mais je n'ai pas vraiment envie de donner le nom du logiciel, et par conscience même en MP je ne souhaite pas présenter le code source en partie ou intégralement.

Désolé.
Je devrais peut-être ne m'en tenir qu'à moi-même et continuer de chercher seul.

En vous remerciant quand même pour votre attention.

Oula, cela ne va pas ta ligne de compilation... Comment veux tu détecter des erreurs facilement si tu fais ceci...
Tu dois utiliser cette ligne : g++ -Wall -c monfichier.cpp 2>log.txt, voir éventuellement g++ -fpermissive -c monfichier.cpp 2>log.txt Tu ne dois le faire pour chaque fichier, un par un, voila pourquoi on te parle de Makefile qui permet d'automatiser cette tache. Pour information :

-fpermissive a écrit :Downgrade some diagnostics about nonconformant code from errors to warnings. Thus, using -fpermissive will allow some nonconforming code to compile.