Erreur compilation sous Linux

Bonjour,

J'avais lros d'un précédent poste vaguement parlé de ce genre de problème lors de la compialtion.
Mais j'ai développé un projet en C++ sur Windows 64bit sur Visual Studio, il fonctionne parfaitement bien, cependant, je l'ai récupérer pour le recompiler sous linux, un ubuntu sous codeblocks, et j'ai ce genre d'erreurs:

Pièce jointe 504763

J'ai réussi à en corriger quelques unes, j'ai linké les librairies et dépendances mais j'ai des problèmes de ce genre, je me demande si ça ne peut pas venir du compilateur ou quoi.

Bonjour,

Sans le code, cela sera difficile de voir ce qui bloque. Il semble qu'il y ai une erreur avant le #include <stdio.h>, cela peut notamment arriver lorsque l'on oublie un ';' en fin de déclaration de structure ou de classe (mais il y a d'autres cas aussi).
Pour le #include "tchar.h", j'espère pour vous qu'il ne provient pas d'une bibliothèque purement Windows.

Bonjour,

Merci pour ta réponse LittleWhite.
Dans l'ordre voilà les include tel qu'ils sont dans mon projet:


Pièce jointe 504806
Pièce jointe 504816

Je me demandais si à des moments ça ne pouvais pas venir de lib qui causerait le problème, mais en soit je ne vois pas.

Bonjour,
Qu'est-ce que cstdlib.h ?

Bonjour Elias,

Pour le coup il ne sert plus à rien.
Je l'ai enlevé.

Bonjour,
Pourriez-vous copier ici qu'est-ce qui se trouve sur les lignes 151, 157, 163 dans votre /usr/include/stdlib.h ?

Salut,

Citation:

---

Envoyé par EliasF00F

Bonjour,
Pourriez-vous copier ici qu'est-ce qui se trouve sur les lignes 151, 157, 163 dans votre /usr/include/stdlib.h ?

---

Ca, ca ne servira à rien : stdlib.h est un fichier d'en-tête spécifique à la bibliothèque standard du C (qu'il faudrait d'ailleurs remplacer par cstdlib en C++ :aie:)

@eristof72 :

Dans ton premier message, on voit à l'impression écrant qu'il y a un ascenceur vertical dans la liste des erreurs. Cela implique qu'il y a très certainement des erreurs bien avant celle que tu nous a présentées.

Le problème est connu : il arrive régulièrement au compilateur de "perdre les pédales" après avoir été confronté à une première erreur, ce qui l'incite à nous "pourrir la vie" avec toute une série de "faux positifs" qui ne découlent que ... de sa perte de pédales.

De prime abord, tu peux faire confiance aux développeur de la bibliothèque standard du C (vu que stdlib.h est un fichier d'en-tête fourni par eux) pour fournir des fichiers qui tiennent parfaitement la route, et qui ne contiennent absolument aucune erreur.

Il faudrait donc remonter le log de compilation jusqu'à trouver la toute première erreur qui apparait dans un de tes fichiers à toi, car l'expérience démontre à loisir que le problème vient toujours de notre propre code ;)

Une fois que tu auras trouvé la toute première erreur (car il peut y avoir quelque avertissements avant qu'elle ne soit affichée), tu aura déjà fait un grand pas dans la résolution de ton problème ;)

NOTA : au lieu de t'em...der à créer des impressions écran, fais plutôt un copier / coller de ton code et des erreurs de compilation que tu obtiens, et utilise le bouton en forme de # qui se trouve au dessus de la zone d'édition du message pour en assurer une mise en forme correcte.

Vu que tu utilises code::blocks, tu peux aisément copier le contenu des différents logs qui se trouvent en bas en faisant un clique droit sur n'importe quelle ligne de log, et en choisissant l'option "Copy contents to clipboard" ;) .

Cela facilitera la vie de tout le monde : la tienne parce que c'est quand même plus facile que de commencer à créer des images et à les transférer sur internet, et la notre, car nous pourrons à notre tour copier et coller le code et / ou le log de compilation chez nous, pour les étudier à notre aise ;)

Bonjour,
Et moi aussi, j'ai absolument confiance aux développeurs de la bibliothèque standard du C.
D'un autre côté, on pourrait y voir qu'est-ce que le compilateur ne trouve pas.

Bonjour,

Citation:

---

au lieu de t'em...der à créer des impressions écran, fais plutôt un copier / coller de ton code

---

Oui c'est ce que je comptais faire, mais je ne pouvais pas copier mon code ici, j'ai screen mon code depuis une VM, sur le moment je ne pouvais pas faire de copier coller alors qu'il devait être activé.

Citation:

---

@eristof72 :

Dans ton premier message, on voit à l'impression écrant qu'il y a un ascenceur vertical dans la liste des erreurs. Cela implique qu'il y a très certainement des erreurs bien avant celle que tu nous a présentées.

Le problème est connu : il arrive régulièrement au compilateur de "perdre les pédales" après avoir été confronté à une première erreur, ce qui l'incite à nous "pourrir la vie" avec toute une série de "faux positifs" qui ne découlent que ... de sa perte de pédales.

---

La première erreur c'est cette ligne :

Code:

---

1 2	/usr/include/wchar.h|564|error: missing binary operator before token "("

---

Sans le

Code:

---

1 2	#include <tchar.h>

---

J'ai 50 erreur et plus, avec, j'en ai plus que 22 .
ça ne m'arrive bien qu'avec codeblocks sous linux, avec Visual Studio sous windows je n'ai pas cette erreur.

Tu ne vas quand même pas me dire que, sur toutes ces erreurs, la seule qui soit issue d'un fichier, sur les 22 erreurs (ou sur les 50) que tu obtiens, qui soit proche de ton projet est

Code:

---

fatal error : tchar.h No such file or directory

---

:question:

Note que cela se peut, car je ne suis pas sur du tout que ce fichier ne soit pas propre à windows :aie:

Il se pourrait du coup que ce soit l'un des symboles préprocesseurs qui soit incorrectement défini (un -D_windows ou quelque chose du genre), ou incorrectement utilisé ;)

Ceci étant dit, en observant plus attentivement ton impression écran, je remarque quelques problèmes :

• cstdlib.h n'existe pas : il faut inclure soit cstdlib (sans le .h, qui est la version C++ du fichier) soit stdlib.h (qui est la version C du fichier), avec une nette préférence pour cstdlib
• stdio.h est un fichier d'en-tête issus du C, préfère utiliser cstdio (sans le .h, qui est la version C++ du fichier), si tu en as vraiment besoin
• il en va de même pour les fichier string.h et time.h, auxquels on préférera respectivement les fichier cstring et ctime (sans le .h) si on en a vraiment besoin
• memory.h me pose beaucoup plus de problèmes, car je ne suis pas sur du tout qu'il s'agisse d'un fichier issus de la bibliothèque stancard du C, étant donné qu'il n'y a pas de fichier correspondant cmemory. Or, il existe en C++ un fichier appelé memory (sans le .h) qui fournit les fonctionnalités relatives aux pointeurs intelligents et à la gestion dynamique de la mémoire. Ne serait-ce pas ce fichier dont tu aurais besoin :question:

Si j'étais toi, je commencerais déjà par supprimer l'inclusion de ces fichiers, en commentant l'ensemble du code, pour n'avoir une fonction main vide, et en me contentant d'inclure les fichiers issus de cpprest.

Si un code proche de

Code:

---

1 2 3 4 5 6

#include <cpprest/filestream.h> #include <cpprest/streams.h> /* et tous les autres cpprest/XXX */ int main(){   }

---

afin de voir si cela compile correctement (cela ne devrait normalement poser aucun problème).

Une fois que cela compile, je décommenterais les instructions de la fonction main les une après les autres, en compilant à chaque fois, afin de déterminer, pour chaque instruction:

1. si elle nécessite un fichier d'en-tête supplémentaire (et, lequel, le cas échéant)
2. si l'inclusion de ce fichier d'en-tête pose problème.

Ce ne sera qu'à partir de là que tu pourras te faire une idée "relativement précise" du problème ;)

D'un autre coté, je persiste et signe : si nous disposions de ton code complet (celui que tu as personnellement écrit pour le fichier dont tu nous montre l'impression écran), nous aurions surement plus facile à t'aider ;)

Bonjour,

Merci pour vos réponses.
J'ai déjà essayé en commentant tout le code, en enlevant les méthodes, ça continuait à buguer jusqu'au moment ou j'ai enlevé :

Code:

---

1 2 3

#include <iostream> #include <stdio.h>

---

J'ai dû enlever tout les includes jusqu'au dernier pour que ça compile avec plus ou moins bien...