MinGW comportement ennuyeux, parfois compile, parfois non?

Question

Je compile et débogue mon petit projet avec msys et MinGW. Parfois, il compile très bien, mais environ 2/3 du temps imprime à la place ce message d'erreur:

include/player.h:1:0: fatal error: can't create precompiled header 
bazglx.exe:invalid argument 
compilation terminated. 
make: *** [bazglx.exe] Error 1 

La ligne supérieure était en finnois si je devais traduire et il ne peut pas être identique à un anglais. Voici mon makefile:

CC = g++ 

IDIR = include 
ODIR = obj 
SDIR = src 


CFLAGS = -I $(IDIR) -static-libgcc -static-libstdc++ -Wall -ggdb 
LFLAGS = -lSDL_gfx 

_OBJ = main.o init.o mainloop.o render.o map.o player.o 
_DEPS = init.h mainloop.h render.h map.h player.h 

OBJ = $(patsubst %.o, $(ODIR)/%.o, $(_OBJ)) 
DEPS = $(patsubst %.h, $(IDIR)/%.h, $(_DEPS)) 

$(ODIR)/%.o:$(SDIR)/%.cpp 
    $(CC) $^ -o $@ `sdl-config --cflags` $(CFLAGS) -c 

bazglx.exe:$(OBJ) $(DEPS) 
    $(CC) $^ -o $@ `sdl-config --libs --cflags` $(CFLAGS) $(LFLAGS) 

Parfois, il affiche même le message d'erreur, mais crée un exe corrompu. Il n'y a rien de spécial au début du fichier qu'il blâme et il a même blâmé les autres fichiers. C'est vraiment déroutant et ennuyeux et ça ralentit vraiment mes progrès.

Answer 1

Cette règle est erroné:

bazglx.exe:$(OBJ) $(DEPS) 
    $(CC) $^ -o $@ `sdl-config --libs --cflags` $(CFLAGS) $(LFLAGS) 

Il provoque $(CC) à invoquaient la liste des fichiers d'en-tête comme entrées en plus des fichiers objets. Le compilateur essaiera de précompiler les en-têtes dans le fichier de sortie bazglx.exe (l'un après l'autre, en écrasant chaque fois le précédent), puis il liera les fichiers objet au fichier de sortie (en l'écrasant à nouveau) pour produire la sortie.

Vous souhaitez que votre étape de liaison implique uniquement les fichiers objet et les bibliothèques.

Je suppose que vous obtenez une erreur (et ne l'obtenez qu'occasionnellement) car quelque chose empêche GCC d'ouvrir le fichier bazglx.exe lorsqu'il essaie de précompiler include/player.h. Vous pouvez voir un effet similaire (mais avec probablement avec une autre erreur sur la deuxième ligne) si vous tapez la commande suivante en vous-même:

g++ include/player.h -o some-non-directory/bazglx.exe 

un antivirus est peut-être l'ouverture et le traitement des nouvelles instances répétées de bazglx.exe et parfois ce traitement n'est pas fait avant que GCC ne veut le recréer?