Teilfehlschlag: Alte SDK in Docker

Obwohl ich Docker nicht wirklich gut leiden kann, bin ich immer offen dafür, künstlich geschaffene Probleme damit zu lösen … so lange sie “spannend” sind.

Vor einiger Zeit hatte ich doch das Quick-and-Dirty Setup für MSVC 2005 Builds ohne Installation geschildert. Daraus ergibt sich doch die Frage:

Kann man eine “ordentliche” MSVC 2005 Buildumgebung für Docker schaffen?

Antwort: Halb Ja, halb Nein, es kommt darauf an.

Ich, der ich von CMake abhängig bin, schaue leider durch die Finger, aber wer ohne CMake direkt mit NMAKE arbeitet, hat eventuell Glück.

Alte Platform-SDKs (zB. von Server 2003 oder Vista) haben den MSVC++ 2005 integriert und lassen sich tatsächlich in Docker installieren und wenn man das Environment-Script ausführt, springt tatsächlich der Compiler an.

Leider kann CMake damit nicht umgehen und sendet in seinen Test-Routinen Flags, die Runtime falsch einbinden. Damit kann CMake nicht feststellen, welcher Compiler benutzt wird und bricht alles Weitere ab.

Aber vielleicht hilft mein Experiment ja anderen weiter, die direkt mit NMAKE arbeiten. MSBUILD wird leider auch nicht unterstützt und somit kann man auch keine Studio Solutions (*.sln) kompilieren lassen.

Dockerfile für MSVC 2005

Wir starten mit einem Arbeitsordner, z.B.: c:\build2005 Man kopiert sich am besten den Inhalt des Setup Folders einer SDK wie z.B. vom Server 2003 SP1 in ein Unterverzeichnis namens sdk.
Dort sind dann alle MSI Pakete für die Installation drinnen.

Nun legt man eine Textdatei namens c:\build2005\Dockerfile an und fügt folgenden Inhalt ein:

 FROM mcr.microsoft.com/windows/servercore:ltsc2019
 
 COPY ["sdk", "C:/Windows/TEMP/sdk"]
 RUN msiexec.exe /i C:\Windows\TEMP\sdk\PSDK-amd64.msi /quiet /qn
 
 #COPY ["Git-2.31.1-64-bit.exe", "C:/Windows/TEMP/"]
 #RUN C:\Windows\TEMP\Git-2.31.1-64-bit.exe /VERYSILENT /SUPPRESSMSGBOXES `
 #      /NOCANCEL /NORESTART
 #
#COPY ["cmake-3.6.3-win64-x64.msi", "C:/Windows/TEMP/"]
#RUN msiexec.exe /i C:\Windows\TEMP\cmake-3.6.3-win64-x64.msi /quiet /qn
#RUN SETX PATH "%PATH%;C:\Program Files\cmake\bin"

ENTRYPOINT  ["C:\\Windows\\System32\\cmd.exe","/K",  `
"C:\\Program Files\\Microsoft Platform SDK for Windows Server 2003 R2\\SETENV.CMD", `
"/XP64","/RETAIL"]

Es installiert die PSDK für AMD64. Optional hatte ich noch eine GIT und die CMAKE Installation dabei.

Im ENTRYPOINT wird das Build-Environment auf WinXP für Releases (Retail) aktiviert.

Wenn wir docker build -t build2005:1.0 . im Verzeichnis c:\build2005 ausführen, sollte Docker ein neues Images mit dem SDK einrichten.

Wenn wir dieses dann mit docker run -it build2005:1.0 ausführen, können wir auf der Konsole bereits NMAKE und CL nutzen.

Wenn man aber CMAKE anwirft, erscheinen Fehlermeldungen wie:

LINK : warning LNK4012: invalid value 'x64', must be 'AM33, AMD64, 
       ARM, CEE, EBC, IA64, M32R, MIPS, MIPS16, MIPSFPU, MIPSFPU16, 
       MIPSR41XX, SH4, SH5, THUMB, or X86'; option ignored
testCCompiler.c.obj : error LNK2001: unresolved external symbol _RTC_Shutdown
testCCompiler.c.obj : error LNK2001: unresolved external symbol _RTC_InitBase

Weitere Tests haben ergeben, dass das Kompilieren einer einfachen “Hello World” Test-EXE mit der Option /MD (dynamische CRT) ein funktionierendes Programm produzierte, während /MT (statische CRT) zu vielen Fehlern führte. Problem waren fehlende Security-Cookies und Runtime-Checks:

main.obj : error LNK2001: unresolved external symbol _RTC_Shutdown
main.obj : error LNK2001: unresolved external symbol _RTC_InitBase
LIBCMT.lib(mbctype.obj) : error LNK2001: unresolved external symbol 
                                         __security_check_cookie
LIBCMT.lib(setlocal.obj) : error LNK2001: unresolved external symbol 
                                          __security_check_cookie
LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol 
                                       __security_check_cookie

Fazit

Also entweder fehlt mir da noch eine essentielle Einstellung, oder die SDK Installation kann nicht ohne Weiteres alle Projektformen durchbauen. Gerade statische Bibliotheken sind im GATE Projekt wichtig und auch CMake brauchte sie für seine Tests.

Man muss auch hinzufügen, dass das SDK in Docker nur als 64-bit Setup läuft und dieses auch nur 64-bit Projekte bauen kann.
Es kann schon sein, dass der 64-bit Support damals noch unvollständig war, weil 32-bit den Standard darstellte.
Auch die VC 2005 Express Variante war nur auf 32-bit fixiert.

Naja … auch Misserfolge gehören zum Leben.
Und vielleicht finde ich die Lösung ja ein anderes Mal.