4. CL /EHsc hello.cpp (hello.cpp ist ein Kommandozeilenprogramm) gibt Linker Fehler

CL /EHsc hello.cpp (hello.cpp ist ein Kommandozeilenprogramm) gibt Linker Fehler

  • J

    Will mit Visual Studio 2010 professional mittels Kommandozeilen-Tool CL ein Hello, world (hello.cpp) übersetzen:

    // Visual Studio 2010 command line compiler "Hello, world!" test (cl ...)

#include <iostream>

using namespace std;

int main(int argc, char *argv[]) {
    cout << "Hello, world!" << endl;
    return 0;
}

    Das CL-Kommando lautet:

    cl /EHsc hello.cpp

    Object file wird erstellt aber dann bekomme ich eine ellenlange Fehlermeldung beim Linken. Sie beginnt mit:

    hello.cpp
    Microsoft (R) Incremental Linker Version 10.00.30319.01
    Copyright (C) Microsoft Corporation. All rights reserved.

    <?xml-stylesheet "type=text/xsl" "href=ActivityLog.xsl?>"
    <activity>
    <entry>
    ...

    und endet in Zeile 2375 mit:

    LINK : fatal error LNK1181: cannot open input file 'type=text/xsl.obj'

    Vermutlich muss man nur noch irgend einen Compiler Switch setzen, aber welchen. Bin beim Googeln auf ähnliche Fragen gestoßen, aber eine wirkliche Antwort konnte ich nicht finden. Ähnliches/gleiches(?) Problem z. B. hier

    0
  • Mod

    Kann es sein, dass Du andere Programme hast, die im Pfad zuerst gefunden werden dich auch LINK.EXE heißen.

    Bei mir geht das ohne Probleme. An /EHsc liegt es gewisslich nicht. Denn das wird IMHO nur im Compiler und nicht im Linker verarbeitet.

    Der Compiler läuft ja durch, aber der Linker nicht.

    0
  • J

    Auf dem Rechner ist zwar auch noch Visual Studio 2005 installiert, aber es wird der richtige Linker (und auch das richtige CL.EXE) aufgerufen. Ich habe es auch getestet, in dem ich CL.EXE mit dem absoluten Pfad aufgerufen habe, gleiches Ergebnis.

    Merkwürdig ist, wenn ich (nach der Fehlermeldung bei cl hello.cpp) danach:

    link hello.obj

    aufrufe, wird hello.exe ohne jede Fehlermeldung erstellt und funktioniert.

    Mit:

    cl hello.obj

    kommt dagegen wieder die Fehlermeldung (auch wenn ich es mit absolutem Pfad aufrufe).

    Bin mir auch ziemlich sicher, dass cl.exe funktioniert hat, solange nur Visual Studio 2005 installiert war.

    Merkwürdig ist, dass es sich jetzt auch mit Visual Studio 2005 nicht mehr compilieren lässt (gleiche Fehlermeldung), wenn ich die VS2005 Kommandozeile öffne.

    0
  • J

    So Lösung gefunden (habe den Link schon damals gefunden, aber stand irgendwie auf der Leitung):

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/9142d67a-a41c-419a-90ce-e964d29e9391/lnk1181-xslobj?forum=vclanguage

    Der durch die Umgebungsvariablen TEMP und TMP angegebene Pfad darf keine Leerzeichen enthalten :-| Aber der bei der Installation von Windows angegebene Eintrag für die TEMP heißt:

    TEMP=C:\Dokumente und Einstellungen\hps\Lokale Einstellungen\Temp

    Na ja gebe ich halt im Visual Studio Command Prompt (2010) einfach:

    SET TEMP=C:\TEMP
    SET TMP=C:\TEMP

    ein, das Verzeichnis existiert für DOS-Kompatibilität bei mir sowieso auf jedem C: Laufwerk. Und da die Environment-Variablen dabei nur für den aktuellen Prozess gesetzt werden (den Visual Studio Command Prompt) stört das nicht weiter. Alle anderen Programme (auch andere direkt, bzw. nicht vom Visual Studio Command Prompt gestarteten Eingabeaufforderungen) nutzen weiterhin die normalen TEMP/TMP-Umgebungsvariablen von Windows.

    0

  • Uff, das ist ja wieder mal beknackt!

    Scheint aber mehrere Programme zu geben die Probleme mit Spaces im TEMP Pfad haben.
    Ich erinnere mich auch dass mir in der Arbeit ein Installer untergekommen ist der mit Spaces im TEMP Pfad nicht funktioniert hat.

    Und jetzt hab' ich einfach mal nachgeguckt was mein privater PC (Windows 8.1) als TEMP eingestellt hat.
    Die User-spezifische Environment-Variable TEMP ist bei mir auf %USERPROFILE%\AppData\Local\Temp gesetzt.
    Trotzdem bekomme ich in cmd.exe folgenden Output:

    C:\Users\hotzenplotz>echo %USERPROFILE%
C:\Users\hotzenplotz

C:\Users\hotzenplotz>echo %TEMP%
C:\Users\HOTZEN~1\AppData\Local\Temp

    D.h. da muss irgend eine Windows 8.1 Magick greifen die sicherstellt dass TEMP immer ein 8.3 kompatibler Pfad ist. (IIRC sorgt Windows beim Erzwingen von 8.3 kompatiblen Pfaden auch dafür dass diese keine Leerzeichen enthalten. D.h. es werden auch grundsätzlich 8.3 kompatible Pfade in die "~" Variante verwandelt wenn sie Leerzeichen enthalten.)

    Bei Windows XP gab es diese TEMP Magick IIRC noch nicht, Windows 7 bin ich nicht sicher.

    0
Anmelden zum Antworten