Vista et gcc - Page 1

yop,

Je rencontre un petit problème en essayant de faire fonctionner gcc (et g++) sous Vista. Il semblerait que le problème soit connu, à en juger par le nombre de topics que me donne une recherche sur Google, mais je n'ai trouvé aucune solution. Voici les détails :

- Lors de la compilation d'un fichier, gcc ne trouve pas "cc1.exe"; ce problème est simple à résoudre, et c'est cette solution qu'on trouve partout sur le net, il suffit de déplacer l'exécutable cc1.exedans le même dossier que gcc. Mais ça ne suffit pas.
- L'autre problème est que gcc n'arrive pas à trouver les includes par défaut. Je ne sais pas comment régler ça, puisque je ne sais pas comment gcc faisait avant pour connaitre le dossier contenant les .h de base, toujours est-il que maintenant ça ne fonctionne plus ("no include path in which to search for stdio.h", etc). Il serait possible d'ajouter un "-Ichemin_complet_vers_le_dossier_include" en argument à gcc, mais c'est une solution qui rend le Makefile relatif au système, et qui en plus ne fonctionne qu'avec g++ (gcc continue à raler, je ne sais pas pourquoi).

Quelqu'un aurait une idée pour résoudre ça ? (je cherche depuis tout à l'heure, je n'ai pas trouvé d'autre solution que celle qui s'arrête à déplacer cc1.exe et deux autres .exe)

Merci

y'a pas une betise d'environnement avec GCC_EXEC_PREFIX , GCC_DIR ou autre?

CPATH ?

Il y en a plusieurs, cf. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Environment-Variables.html#Environment-Variables (je dirais que c'est plutôt C_INCLUDE_PATH ? sinon pour le cc1.exe ça doit être soluble avec une variable d'environnement aussi...)

-Idir
you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that).
(donc c'est probablement pour ça que gcc n'est pas content)
C_INCLUDE_PATH a l'air de faire la même chose que -isystem mais seulement pour gcc, sinon c'est CPLUS_INCLUDE_PATH pour g++

ça ne semble pas marcher (aucun changement, j'ai tjrs l'erreur comme quoi aucun search path n'a été défini); et puis sous XP ça a toujours marché sans cette variable :/

Ah ? et avec -isystem ?

et puis sous XP ça a toujours marché sans cette variable :/

Oui mais peut-être que le chemin était hardcodé dans l'exécutable et qu'il a changé dans vista ? (la variable d'environnement n'étant censée servir à quelque chose que si le chemin hardcodé ne marche pas)

exactement pareil

Juste pour info Vista 64 bits ou 32 bits ?

32 bits

C'est clair ya des tonnes pbms connus avec gcc/mingw/cygwin avec vista... je suis pas sur que tous ai été résolus..

visiblement ça serait ça le problème : http://www.nabble.com/MinGW,-GCC-Vista,-t3707859.html

y'a des gens qui l'ont résolu en changeant juste la constante et en recompilant GCC, mais j'ai rien pr le faire, et visiblement y'en a pas un d'eux qui s'est dit que ça pourrait être une bonne idée de partager un binaire corrigé plutôt que d'indiquer comment résoudre le pb

Forcément ce sont les développeurs de GCC.

bah ouais, ça n'empêche que c'est super pratique quand on est sous Windows et qu'on a précisément besoin de gcc pour pouvoir compiler...

(même si j'avais autre chose pr compiler, quel intérêt de recompiler un truc pr arriver exactement au même résultat qu'en téléchargeant le binaire directement ?)

Installe XP, compile, Reinstall Vista.
C'est prêt.

ouéééé deja que compiler gcc c'est long

Bah, pas tant que ca en fait. Les compilateurs C et C++ doivent se faire en moins d'une demi-heure sur un ordi moderne.

Ben ecoute tu viendras nous le dire au boulot hein ^^

Si tu veux

J'ai installé gcc justement il y a quelques jours sur Vista. Ma solution est de rajouter le chemin de cc1 dans la variable d'environnement PATH de windows.

j'ai déplacé cc1 dans le même dossier que gcc/g++, ça évite d'avoir à ajouter un deuxième chemin dans le PATH, mais le problème se situe au niveau de l'inclusion des headers, pas de la localisation des exécutables :/

(j'ai lu cette solution pas mal de fois sur le net, mais je ne comprends pas en quoi elle résout le problème ? enfin si, on peut compiler des exécutables qui n'utilisent aucun header standard :/)

essaie avec le PATH pour voir parce que chez moi je peux compiler un hello world avec <iostream> sans problème

avec g++ oui, mais essaie de faire un .c, d'y inclure <stdio.h>, et de le compiler avec gcc par exemple

[edit] quoique non, même pb avec g++ en fait, mais de toutes façons cc1 et cie sont dans le même dossier que gcc/g++ qui les trouvent sans problème du coup. tu es sûr que tu utilises bien le gcc de MinGW et non pas Cygwin ?

Oui j'utilise bien MinGW (Cygwin souffre toutefois du même problème). Effectivement je n'ai pas fait le test avec le compilateur C (uniquement le C++) mais je suppose que c'est pareil. Je ne suis pas chez moi donc je ne peux pas faire le test tout de suite. En tout cas ça marche bien. Donc tu as testé avec le PATH et ça ne marche pas ? Et quand tu essaies de lancer cc1 depuis une console de commandes il te fait quoi ?

oui j'ai testé avec le PATH, mais j'ai toujours le même résultat : "no include path in which to search for iostream", et ça foire bien sûr puisque rien n'est défini. si je lance cc1 depuis une console il attend je ne sais quoi sur stdin, comme d'habitude

ok, donc tu as un deuxième problème de path que je n'ai pas :-/ Je regarde ça demain et je te tiens au courant.

oki, thx ^^

c'est possible que le path des includes soit déterminé à partir du path de cc1 ? si oui alors avec une copie de cc1 ailleurs qu'à son emplacement normal gcc serait perdu et ne pourrait plus retrouver ses includes ^^ (ce qui pourrait expliquer que blackghost n'a pas le problème alors que vous avez le même PATH)

(enfin c'est pas sûr du tout que ça soit ça la vraie raison, je dis ça juste au cas où)

bah initialement j'avais aussi testé sa solution, à savoir laisser cc1 à sa place et ajouter son chemin dans le path, mais j'ai exactement le même problème :/

comment les chemins vers les .h à inclure sont déterminés, normalement ? parce que le dossier "include" ne figure jamais dans le path ni dans aucun fichier de configuration, il me semble (et habituellement ça marche très bien comme ça; enfin jusqu'à Vista)

C'est expliqué dans le manuel (cf. plus haut) mais apparemment c'est faux (cf. ta réponse), donc...
j'étais persuadé que le chemin était hardcodé dans l'exécutable, et que les variables d'environnement permettaient l'override de ce chemin hardcodé