2016-04-25 18 views
1

Ich arbeite an einer grundlegenden Makefile-Datei zum Testen der Kompilierung unserer Quellen für alternative Microsoft-Umgebungen wie Windows Phone. Ich öffnete eine AR2012 ARM Developer Eingabeaufforderung und lief nmake auf dem Makefile. Es ergab:Warum versucht ARMs cl.exe, x86 oder x64 App von ARM Developer Command Line zu erstellen?

nmake /f makefile.namke 
... 

cl /c cryptlib.cpp cpu.cpp... 

cryptlib.cpp 
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338): 
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported. 
cpu.cpp 
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338): 
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported. 
... 

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 
\VC\BIN\x86_ARM\cl.EXE"' : return code '0x2' 
Stop. 

"Desktop-Anwendungen" ist ein bisschen zweideutig, so suchte ich Microsoft für die Bedeutung des Begriffs. Es scheint, dass die Toolchain x86 oder x64 Metro UI-basierte Anwendungen erstellt.

Ich fühle mich wie ich eine Trennung erleiden, oder Microsoft leidet eine Trennung und ihre Werkzeuge sind fehlerhaft.

Warum versucht Microsofts ARM-Version von cl.exe, eine x86- oder x64-Anwendung zu erstellen, statt für ARM zu kompilieren? Oder warum stellt die Eingabeaufforderung des VS2012 ARM-Entwicklers eine x86- oder x64-Anwendung auf?


Ich habe auch versucht, das Problem zu beheben, aber die vorgeschlagenen Lösungen funktionieren nicht. Jetzt versuche ich zu verstehen, was auf den höchsten Ebenen vor sich geht.

Zum Beispiel, one answer sagt, um <WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport> zu einem ARM-Eigenschaftsblatt hinzuzufügen, aber das hat nicht funktioniert. Another answer sagt zu CXXFLAGS = /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE hinzufügen, aber das hat auch nicht funktioniert.


Das Makefile ist so einfach wie es nur geht, um die Kompilierung unter Microsofts ARM-Toolchain zu testen.

LIB_SRCS = cryptlib.cpp cpu.cpp ... 
LIB_OBJS = cryptlib.obj cpu.obj ... 

TEST_SRCS = test.cpp bench1.cpp bench2.cpp ... 
TEST_OBJS = test.obj bench1.obj bench2.obj ... 

CXX = cl.exe /nologo 
AR = lib.exe 
CXXFLAGS = 

all: cryptest.exe 

cryptest.exe: $(TEST_OBJS) cryplib.lib 
    $(CXX) $(CXXFLAGS) /ref:cryplib.lib /out:[email protected] $(TEST_SRCS) 

cryplib.lib : $(LIB_OBJS) 
    $(CXX) $(CXXFLAGS) $(LIB_SRCS) 
    $(AR) $(LIB_OBJS) 
+0

_ "...füge 'CXXFLAGS =/D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE' hinzu, aber das hat auch nicht funktioniert." _ - meinst du das wörtlich oder definierst es auf etwas ungleich Null? Zeile 337 dieses Headers prüft seinen Wert, nicht nur seine Existenz. Vermutlich diese cpp Dateien verwenden einige der Win32-APIs, die willkürlich auf ARM nicht zugelassen sind In jeder Instanz, die mir begegnet, bezieht sich "Desktop" immer auf veraltetes Win32, dh nicht WinRT oder UWP. – Notlikethat

Antwort

0

Die richtige Lösung wäre etwas Ähnliches wie /D WINAPI_FAMILY=WINAPI_FAMILY_APP oder /D WINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP hinzuzufügen.

Die Windows SDK-Header haben drei verschiedene API-Subset-Ziele, "Desktop", "App" (die neue "Metro" -App in Windows 8 eingeführt) und "Telefon". Beim Erstellen aus Visual Studio wird die richtige Teilmenge automatisch ausgewählt, abhängig vom Projekttyp. Wenn Sie jedoch manuell erstellen, indem Sie cl.exe aufrufen, müssen Sie das Ziel manuell angeben. (Das ausgewählte Ziel begrenzt, welche Deklarationen in den Headern sichtbar sind und welche nicht in den begrenzteren angezeigt werden.)

Aus der Tradition heraus ist der Desktop der Standard, aber wenn Sie ARM als Ziel wählen, müssen Sie eines auswählen die anderen, da es kein öffentlich unterstütztes Ziel für den Code von Drittanbietern im Desktop-Modus für ARM gibt. (Die WinRT-Tablets hatten einen Desktop-Modus, aber Dritte durften keine Apps dafür bauen.)

Seit Windows 10 und MSVC 2015 müssen Sie nicht zwischen Telefon und App unterscheiden, sondern verwenden "App" für beide. Die andere Flagge, die vorgeschlagen wurde, _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, im Grunde sagt die Header so zu tun, als ob Sie für die Desktop-API-Familie auch für ARM erstellen dürfen. Um es zu verwenden, scheint es so zu sein, dass Sie es so definieren sollten: /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 (d. H., Es ist einfach nicht ausreichend, Sie sollten es auf 1 definieren). Für einfachen Code, der nicht viel von der Windows-API verwendet, sollte dies ebenso gut funktionieren, aber die bessere Lösung besteht darin, das echte API-Ziel zu deklarieren, um richtige Warnungen zu erhalten, wenn versucht wird, APIs zu verwenden, die nicht verfügbar sind.