make: Interrupt / Exception abgefangen

33

Ich verwende Make aus der MinGW-Distribution. Es hat immer funktioniert, aber in letzter Zeit habe ich den folgenden Fehler bekommen:

> make clean
make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x0040b0ac)

Und der jeweilige Teil sieht so aus:

clean:
    del /S /Q *.o > nul
    del /S /Q *.cy.c > nul
    del /S /Q *.pyc > nul
    del /S /Q *.pyo > nul
    if EXIST build (rmdir /S /Q dist > nul)

Ich habe keine Ahnung, woran das liegt. Vor allem, weil es immer einwandfrei funktioniert hat.

windows make mingw orlp
quelle
1
Haben Sie versucht, make zu aktualisieren? gnu.org/software/make
Fabián Heredia Montiel

Antworten:

46

Ich bekam auch eine Ausnahme:

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4227d3)

Könnte ein anderer Grund sein, aber dieses Problem verursacht wird offenbar , wenn die PATH - Variable Klammern enthält (, )wie es auf Win Vista / 7 der Fall ist. Leider ist die verfügbare GNU für Windows hoffnungslos veraltet.

Mein Problem wurde durch Erzwingen der makeVerwendung der richtigen Shell behoben : Fügen Sie die folgende Zeile am Anfang Ihres Makefiles ein.

SHELL=C:/Windows/System32/cmd.exe
Norbert P.
quelle
Tolle Lösung, aber ich weiß nicht, warum es nicht funktioniert hat, ich habe keine Klammern in meinen Umgebungsvariablen
forsubhi
1
Könnte das auch mit der Länge des PFADS zusammenhängen? In meinem Fall hatte mein PATH bereits viele Klammern ohne Probleme (bis ich weitere Sachen installiert habe); Das Ersetzen aller Instanzen von C:\Program Filesmit C:\PROGRA~1und C:\Program Files (x86)mit hat C:\PROGRA~2das Problem für mich behoben. +1 :-)
Cameron
Ich hatte auch dieses Problem und wechselte zu einer neueren Version von make: equation.com/servlet/equation.cmd?fa=make - Dies hat das Problem nicht behoben, aber es behandelt die Ausnahme besser und sagt Ihnen, was passiert: sh: C:\Program: No such file or directoryis Die erste Zeile erhalte ich, wenn ich die SHELLVariable nicht übergebe . Grundsätzlich enthält jede Instanz von "Program Files" auf dem PATH einen Speicherplatz, der nicht ordnungsgemäß maskiert ist (was make betrifft). Es ist nicht die Länge des Pfads, sondern die Leerzeichen, die dieses Problem verursachen. Dies erklärt, warum die Verwendung eines Makros ohne Leerzeichen dieses Problem behoben hat.
Johannes
Diese Lösung hat bei mir funktioniert.
Robert Stiffler
8

Ich hatte dieses Problem, als ich das bin-Verzeichnis von Git der PATHUmgebungsvariablen hinzufügte . Der Grund scheint zu sein, dass Git mit einer Version von MSYS ausgeliefert wird und dies mit MinGW in Konflikt zu geraten scheint (möglicherweise liegt kein Konflikt vor, wenn es sich um die richtige Version von MSYS und / oder MinGW handelt, aber das ist nur eine Vermutung).

Stellen Sie also sicher, dass sich in Ihrem System keine (andere) MSYS - Distribution befindet PATH.

Zündgerät
quelle
1
Git Pfad zum Bin-Verzeichnis war das Problem für mich! Gut gemacht !
TridenT
3

Als ich Norbet P. antwortete, stellte ich fest, dass das Hinzufügen von:

PATH=

Oben in meinem Makefile wurde dieses spezielle Problem für mich behoben.

Mark Tolley
quelle
1
Ich gebe keine -1, aber das ist eine schrecklich schlechte Antwort. Sie können PATH nicht einfach zurücksetzen !!! Das ist eine sehr schlechte Übung! Manchmal hängt die Programmkompilierung von Informationen in PATH ab.
Der Quantenphysiker
3

Dieser makeFehler ist zumindest in behoben

GNU Make 3.82
Built for i686-pc-mingw32

.

Armali
quelle
Woher bekomme ich diese Version?
SHOUBHIK BOSE
1
IIRC, ich habe es von hier bekommen .
Armali
2

Ich habe GnuWin verwendet, bis mir klar wurde, dass die letzte Veröffentlichung bereits am 26. November 2006 veröffentlicht wurde . Das ist ein bisschen lahm und hat die oben genannten Probleme verursacht. Das Setzen von SHELL = C: /Windows/System32/cmd.exe behebt zwar einige Probleme, aber das Ausführen eines solchen alten Codes auf neuen Betriebssystemen fühlt sich unsicher an

MinGw ist eine sicherere Wette. MinGw ist die Abkürzung für "Minimalist GNU for Windows" und ist auf dem neuesten Stand und enthält make und andere Tools

http://sourceforge.net/projects/mingw/files/

user246954
quelle
1
Hast du die Frage überhaupt gelesen?
Orlp
1

Der Windows-Fehlercode 0xC0000005weist auf eine Zugriffsverletzung oder einen Segmentierungsfehler hin.

  • Ist Ihre MinGW-Installation beschädigt?
  • Ist Ihr System richtig konfiguriert? Wurden kürzlich Systemeinstellungen geändert?
  • Gibt es Hardwareprobleme auf Ihrem System? Möglicherweise müssen Sie die Festplatte mit CHKDSK scannen oder einen Speichertest wie Memtest86 + durchführen .
bwDraco
quelle
-1

In meinen Kompilierungsprotokollen habe ich festgestellt, dass "SHELL = sh" übergeben wurde, obwohl ich mich auf einer Windows-Plattform befinde. Mein Makfile sah so aus:

ifneq (, $ (findstring win, $ (RDI_PLATFORM))) SHELL = CMD endif

Sobald ich das ifneq kommentierte und es beendete, fing es an zu arbeiten. Nicht sicher, warum die Plattform nicht richtig interpretiert wurde.

martinv
quelle
1
Dies ist keine Antwort auf die ursprüngliche Frage. Wenn Sie einen Autor kritisieren oder um Klarstellung bitten möchten, hinterlassen Sie einen Kommentar unter seinem Beitrag. Sie können jederzeit Ihre eigenen Beiträge kommentieren. Wenn Sie über eine ausreichende Reputation verfügen, können Sie jeden Beitrag kommentieren .
DavidPostill