Vista et gcc - Page 2

Alors dans mon PATH j'ai :

C:\mingw\bin;c:\mingw\libexec\gcc\mingw32\3.4.2

J'ai fait le test avec le compilateur C et le compilateur C++, ça passe avec les 2. Tu n'as pas d'espace dans ton chemin ?

Sally > je ne pense pas que le chemin soit hardcodé, ça ne fonctionnerait jamais quand tu installes gcc sous Windows (donc déjà compilé), puisque l'install te laisse choisir le dossier de destination et que ça fonctionne correctement (sauf si un exe vient patcher gcc après pour lui injecter le chemin d'installation, mais ça m'étonnerais quand même)

blackGhost > j'ai l'équivalent de ton path (mais un dossier d'install différent), et non, aucun espace dans les dossiers :/

Si c'est pas hardcodé ni dans l'environnement ni dans un fichier ni dans un paramètre, il ne reste guère que la base de registres ?

nan, je pensais à un truc genre "../include" par rapport à ton path (e:\mingw\bin dans ton path => recherche dans e:\mingw\include)

./33 > GCC qui utilise la base de registre ? J'en doute fort quand même

Et quand tu compiles en spécifiant le chemin des include à la main ?

avec g++ ça passe, mais avec gcc ça marche pas, je me prends des tonnes d'erreurs de parsing (j'ai essayé avec -I et -isystem, mais il y a peut-être autre chose à spécifier pour les headers système)

Pour info tu as quelle version de gcc ?

3.4.2

Tout pareil ...peut-être que l'on a une version différente du runtime MinGW ...

bah perso j'ai la version la plus récente disponible sur le site là, je l'ai d/l il y a 3 jours :/

Moi je l'ai dl la semaine dernière ...on doit bien avoir un truc de différent quand même

bah en fait ce qui m'étonne c'est que ça marche chez toi, parce que d'après ce que j'ai lu sur le net, il m'a semblé comprendre que c'était "normal" que ça bug

Ben j'avais été confronté au problème du cc1 mais effectivement j'avais vu que d'autres personnes continuaient d'avoir des problèmes après la résolution de ce premier. Je ne comprends pas pourquoi ça marche chez moi mais pas chez d'autres personnes.

Sinon d'autres problèmes sont apparus avec Vista : le printf("%n" ...) n'a pas un comportement habituel. Résultat : si tu tentes de recompiler gcc toi-même (j'ai tenté une recompil de la version 4.x) il va boucler jusqu'à ce que tu aies un disk full. Ô quelle joie ce Vista ^^

J'avais exactement les mêmes problèmes que toi Zephyr,
mais j'ai trouvé une solution : avec quelque chose de ce type là, j'arrive à compiler mes programmes (en fait moi c'est pour compiler des programmes Qt-OpenSource au départ)

REM C'est assez pratique de mettre ça dans un bat pour faire des tests.
set MINGW_PATH=...
set PATH=%PATH%;%MINGW_PATH%\bin;%MINGW_PATH%\libexec\gcc\mingw32\3.4.2
set C_INCLUDE_PATH=%MINGW_PATH%\include;%MINGW_PATH%\lib\gcc\mingw32\3.4.2\include
set LIBRARY_PATH=%MINGW_PATH%\lib;%MINGW_PATH%\lib\gcc\mingw32\3.4.2

gcc test.c -o a.exe
g++ test.c -o b.exe

Ce qui est bizarre c'est que cette solution je ne l'ai trouvée nulle par sur internet

Sinon j'ai découvert un truc grâce à ça, on n'est plus obligé de rebooter pour que windows prenne en compte les changements de variables d'environnement : tous les programmes lancés après la modif la prennent en compte (mais il ne faut pas qu'ils soient lancé par un programme qui était lancé avant sinon ils héritent des anciennes ).

Twindruff (./45) :
Ce qui est bizarre c'est que cette solution je ne l'ai trouvée nulle par sur internet

Parce que ça ne fonctionne pas, ou en tout cas pas chez moi

T'as quoi comme erreur ?
T'as bien défini la variable d'environnement MinGW pour que les %MinGW% soient remplacé par ton chemin?

C'est bon, il n'y avait qu'une espace en trop

./45 : aucun changement chez moi, les headers sont toujours introuvables :/

Thepro (./48) :
C'est bon, il n'y avait qu'une espace en trop  

Ah oui j'avais rajouté les espaces pour que ce soit plus lisible dans le post je vais les enlever

Zephyr (./49) :
./45 : aucun changement chez moi, les headers sont toujours introuvables :/

Quel header par exemple ?

tous. enfin tous ceux qui ne sont pas à moi (dont je n'indique pas le chemin complet en relatif, quoi)

Ceci ne compile pas alors ?

#include <stdlib.h>

int main(void)
{
	return EXIT_SUCCESS;
}

et avec un -Ichemin du include, il change d'erreur ?

nop compile pas, cannot find stdlib.h; avec un -I vers le dossier des include ça passe pas non plus, il me trouve des parse error dans les headers (mais vu qu'il y a un switch spécialement pour les headers standard, je suppose que c'était dans tous les cas supposé ne pas fonctionner ?)

Zephyr (./53) :
nop compile pas, cannot find stdlib.h; avec un -I vers le dossier des include ça passe pas non plus, il me trouve des parse error dans les headers (mais vu qu'il y a un switch spécialement pour les headers standard, je suppose que c'était dans tous les cas supposé ne pas fonctionner ?)

S'il a changé d'erreur entre le cas où tu mets pas le -I et le cas où tu le mets c'est qu'il a pas pris en compte les variables d'environnement.
Peut être que tu devrais essayer définir les variables dans le système plutôt qu'avec un set.

Ça ne fonctionne pas le ./45 en enlevant toutes les espaces, même en fin de ligne ?

ué j'ai viré tous les espaces. par contre en réessayant je me suis rendu compte que le problème était devenu assez curieux : en redéfinissant les variables d'environnement, les includes de type <fichier.h> fonctionnent depuis mes fichiers, mais pas depuis un fichier header standard.

par exemple, je fais un fichier test.c de ce style :

#include <stdio.h>

int main ()
{
    printf ("test\n");
    return 0;
}

l'include de stdio.h passe, mais il inclut lui-même stddef.h (ou stdarg.h), et là ça ne passe pas (toujours la même erreur, "no path in which to search for stddef.h")... je comprends pas trop comment c'est possible ni la gueule que doit avoir le code derrière pour en arriver à ce genre de résultat, mais toujours est-il que...

touche toi la bite et fais l'avion pour voir ?

Zephyr (./56) :
les includes de type fonctionnent depuis mes fichiers, mais pas depuis un fichier header standard.

Ça me fait la même chose s'il reste une espace à la fin de C_INCLUDE_PATH, enfin c'est le dernier chemin qui devient incorrect...

Thepro > oué mais là il ne reste pas d'espace, j'ai re-vérifié

désolé de l'up mais je viens de chercher comment installer mingw avec une nightly build de codeblocks et j'ai trouvé ça:

http://wiki.codeblocks.org/index.php?title=MinGW_installation
Apparemment,

Thanks to Aaron Giles' Solving the Windows Vista Build Issues for the solution. In summary, the MinGW folder must be "a directory immediately off the root of your hard disk for some reason. So c:\mingw works fine, but c:\tools\mingw won’t.
"

ce qui fait que ça marche chez blackghost.

ça serait pas ça ton souci?