Clang auf Windows benutzen

Ich habe nun drei Male versucht, Clang auf Windows zum Laufen zu kriegen und dabei bestimmt je zwei Stunden in den Wind geschossen. Das erste Mal war mit Clang 3.8.1 auf einer Maschine, auf der MSVC und MinGW installiert waren. Als ich dann etwas kompilieren wollte, griff Clang automatisch auf die MSVC-Standardbibliothek zu und konnte diese nicht kompilieren, entweder weil diese nicht standardkonform sind oder weil Clang zu schlecht ist, Standard-C++ zu kompilieren. Wieso ist es dann der Default, wenn es damit nicht mal out of the box funktioniert? Was auch immer, Visual Studio habe ich sowieso nur auf diesem einen Rechner installiert.
Versuche 2 & 3 waren dann mit Clang 3.8.1 und 3.9.0 auf einer Maschine, auf der nur MinGW (mit GCC 6.2.0) aber kein MSVC installiert ist. OK, nach der Installation mit dem Installer von hier erstmal versucht, etwas zu kompilieren. Anscheinend will Clang noch immer auf MSVC-Libs zugreifen, obwohl diese gar nicht vorhanden sind. OK, dann will ich zum Testen 'mal schnell mit der libstdc++ von meinem GCC kompilieren, weil libc++ schlechter ist (?), dem nach zu urteilen, was ich gehört habe.
Nach zeitintensiver Suche kam ich zum Ergebnis, dass man dafür Clang selbst neu kompilieren muss, weil die Paths hardgecoded sind?!? WTF? Jeder C++-Anfänger kann Pfade aus einem JSON-File extrahieren und öffnen, die Clang-Entwickler aber anscheinend nicht? Und dieser Mist ist ein so hochgepriesener und weitverbreiteter C++-Compiler?

Ist das ein schlechter Witz oder übersehe ich etwas Offensichtliches? Wie kann es so schwierig und kompliziert sein, mit Clang auf Windows ein Hello-World zu kompilieren?

Du bist jedenfalls nicht in der Lage, das richtige Forum zu wählen.

C++ Forumbot

Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

manni66 schrieb:

Du bist jedenfalls nicht in der Lage, das richtige Forum zu wählen.

Danke für deinen hilfreichen Beitrag... wie immer.

Finnegan

klanger schrieb:

Als ich dann etwas kompilieren wollte, griff Clang automatisch auf die MSVC-Standardbibliothek zu und konnte diese nicht kompilieren, entweder weil diese nicht standardkonform sind oder weil Clang zu schlecht ist, Standard-C++ zu kompilieren. Wieso ist es dann der Default, wenn es damit nicht mal out of the box funktioniert? Was auch immer, Visual Studio habe ich sowieso nur auf diesem einen Rechner installiert.

Kommt mir bekannt vor:

C:\Temp>clang-cl hello.cpp
In file included from hello.cpp:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\iostream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\istream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ostream:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios:6:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocnum:7:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cmath:647:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtgmath.h:8:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtr1common(213,22) :  error: use of undeclared identifier 'char16_t'
        struct _Is_integral<char16_t>
...

Aua... stattdessen:

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>clang-cl -fms-compatibility-version=19.00.23918 hello.cpp

C:\Temp>hello
Hello, World!

Bei neueren MSVC-Versionen/Standardbibliotheken muss man Clang ein wenig auf die Sprünge helfen.

klanger schrieb:

Versuche 2 & 3 waren dann mit Clang 3.8.1 und 3.9.0 auf einer Maschine, auf der nur MinGW (mit GCC 6.2.0) aber kein MSVC installiert ist. OK, nach der Installation mit dem Installer von hier erstmal versucht, etwas zu kompilieren. Anscheinend will Clang noch immer auf MSVC-Libs zugreifen, obwohl diese gar nicht vorhanden sind.

Richtige exe-Datei aufgerufen? clang-cl.exe ist per default MSVC-Modus, clang++.exe MinGW(-w64)-Modus, bzw. Linux/unixoider Modus.

klanger schrieb:

OK, dann will ich zum Testen 'mal schnell mit der libstdc++ von meinem GCC kompilieren, weil libc++ schlechter ist (?), dem nach zu urteilen, was ich gehört habe.
Nach zeitintensiver Suche kam ich zum Ergebnis, dass man dafür Clang selbst neu kompilieren muss, weil die Paths hardgecoded sind?!? WTF? Jeder C++-Anfänger kann Pfade aus einem JSON-File extrahieren und öffnen, die Clang-Entwickler aber anscheinend nicht? Und dieser Mist ist ein so hochgepriesener und weitverbreiteter C++-Compiler?

Zu kompliziert gedacht. Pfade sind zwar teilweise hartcodiert, allerding immer relativ zur .exe-Datei des Compilers.
Und wozu libstdc++ kompilieren, wenn du bereits ein MinGW(-w64?) installiert hast? Die simpelste Lösung ist wohl beide "ineinander" zun kopieren mit ihren "lib", "bin" und sonstwas-Verzeichnissen:

C:\Temp>dir C:\mingw-w64

31.03.2016  19:47    <DIR>          .
31.03.2016  19:47    <DIR>          ..
20.07.2016  14:22    <DIR>          bin
31.03.2016  19:46    <DIR>          i686-w64-mingw32
31.03.2016  19:46    <DIR>          include
31.03.2016  19:46    <DIR>          lib
31.03.2016  19:46    <DIR>          libexec
31.03.2016  19:47    <DIR>          msbuild-bin
31.03.2016  19:47    <DIR>          share
31.03.2016  19:47    <DIR>          tools
31.03.2016  19:47    <DIR>          x86_64-w64-mingw32

C:\Temp>c:\mingw-w64\bin\clang++ -std=c++14 hello.cpp

C:\Temp>hello
Hello, World!

Was libc++ betrifft: Meine letzte Info ist, dass diese noch nicht vollständig nach Windows portiert wurde und wohl auch nicht besonders eifrig an dem Port geschraubt wird.
Unter Windows muss man also entweder die MSVC-Standardbibliothek verwenden, oder die libstdc++.

klanger schrieb:

Ist das ein schlechter Witz oder übersehe ich etwas Offensichtliches? Wie kann es so schwierig und kompliziert sein, mit Clang auf Windows ein Hello-World zu kompilieren?

Nein, das ist völlig normal dass man Geduld braucht und einiges selbst herausfinden muss, wenn man Clang unter Windows nicht direkt als drop-in-Replacement für cl.exe verwenden will (Dort liegt der Fokus der Windows-Version).
Ich habe da schon deutlich mehr als die 6 Stündchen rein investiert um das und andere Aspekte der Toolchain so wie ich es mir vorstelle ans Laufen zu bekommen. Unter Linux oder mit XCode ist es zugegebenermassen simpler.
Dennoch ist Clang ein exzellenter Compiler - auch unter Windows. JSON-Configs sind halt nicht das was einen Compiler gut macht.

Finnegan

Danke für deine Hilfe schonmal. Ja, ich verwende clang++.exe, nicht clang-cl.exe.

Was ich nun gemacht habe, ist, mir mit GCC alle Default-Include-Pfade auszugeben. Dann habe ich diese in ein Makefile getan und kompiliere mit clang++ nun mit diesem Schwall an -I-Direktiven. Zumindest findet clang++ nun die Header-Dateien endlich, was schon einmal ein Fortschritt ist. Bleiben nur noch die unzähligen Fehlermeldungen, die durch das Hello-World-Programm entstehen:

C:/Dev/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++\bits/stringfwd.h:63:33: error:
      use of undeclared identifier 'char16_t'
  template<> struct char_traits<char16_t>;

Obwohl ich mit -std=c++14 kompiliere, kommt dieser Fehler. Selbst wenn ich nichts inkludiere und nur einen char16_t / char32_t in der main-Funktion definiere, kommt derselbe Fehler. Dein -fms-compatibility-version=19 behebt das Problem zwar, aber wieso muss ich dieses Flag angeben, wenn ich normalen C++11-Code kompilieren möchte und -std=c++14 schon angegeben habe? Das ist mit clang++.exe wohlgemerkt, nicht mit clang-cl.exe.

C:/Dev/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++\type_trai
ts:337:39: error:
      __float128 is not supported on this target
    struct __is_floating_point_helper<__float128>
                                      ^

Da bin ich ratlos. __float128 ist auf jeden Fall nicht Standard-C++, daher kann ich nachvollziehen, dass clang das nicht kompilieren kann. Diesbezüglich habe ich das hier gefunden, und wenn ich _GLIBCXX_USE_FLOAT128 in der betroffenen Datei tatsächlich undefine, dann geht dieser Fehler auch weg. Auch seine vorgeschlagene Lösung funktioniert. Aber manuell in meiner libstdc++ herumzupfuschen kann nicht die Lösung sein. Vor allem will ich das nicht auf jedem Computer und für jede neue libstdc++- (oder MinGW-) Version machen müssen.

C:/Dev/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w6
4-mingw32/include\stdio.h:167:63: error:
      expected ';' after top level declarator
  int __cdecl __mingw_printf(const char * __restrict__ , ... ) __MINGW_NOTHROW;
                                                              ^

Diesbezüglich habe ich nichts Hilfreiches gefunden.

Finnegan

klanger schrieb:

Was ich nun gemacht habe, ist, mir mit GCC alle Default-Include-Pfade auszugeben. Dann habe ich diese in ein Makefile getan und kompiliere mit clang++ nun mit diesem Schwall an -I-Direktiven.

Hi nochmal! Ich hätte da wenig Vertrauen lediglich die Include-Pfade anzupassen.
Ich habe seinerzeit sowohl Clang als auch GCC und die MinGW-Runtime selbst gebaut (mit Patches von TDM-GCC, z.B. um libwinpthread statisch linken zu können) und
da erschliessen sich einem schon so manche untiefen und jede Menge komplexe Logik was die richtigen Pfade und Dateien angeht.

Warum probierst du es nicht mal mit meinem Vorschlag GCC, die MinGW-Runtime und LLVM/Clang in die selbe Verzeichnissstruktur zu packen?
Unter Linux sind diese Dateien auch alle in einem einzigen Verzeichnisbaum zu finden - man macht es Clang so auf jeden Fall leichter die benötigten Sachen zu finden.

Leider hast du nicht exakt geschrieben, welche MinGW-Variante du verwendest, anhand deiner Posts habe ich da jedoch eine Vermutung und mir nochmal
die Mühe gemacht eine Konfiguration zu installieren, die der deinen entsprechen müsste. Hier mein Protokoll:

1. Unter
https://sourceforge.net/projects/mingw-w64/
Den Installer mingw-w64-install.exe heruntergeladen und die Variante x86_64-6.3.0-release-posix-seh-rt_v5-rev1 nach c:\test\mingw-w64 installiert.

2. Unter
http://llvm.org/builds/
den Windows-Snapshot LLVM-4.0.0-r282394-win32.exe heruntergeladen und nach c:\test\LLVM installiert.

3. Suchergestellt, dass ich meine aktuellen MinGW-Compiler-Pfade nicht mehr in PATH habe.

4. Den Ordner C:\test\compiler erstellt und den Inhalt von C:\test\mingw-w64\x86_64-6.2.0-posix-seh-rt_v5-rev1\mingw64 sowie den Inhalt von C:\test\LLVM dort hin kopiert (alles in eine Verzeichnisstruktur):

C:\test\compiler:
bin  build-info.txt  etc  include  lib  libexec  licenses  msbuild-bin  opt  share  tools  x86_64-w64-mingw32

C:\test\compiler\bin:
addr2line.exe                 cpp.exe               genpeimg.exe        libstdc++-6.dll      readelf.exe
ar.exe                        dlltool.exe           gfortran.exe        libwinpthread-1.dll  scan-build.bat
as.exe                        dllwrap.exe           git-clang-format    lld.exe              scan-view
c++.exe                       dwp.exe               gprof.exe           lldb.exe             size.exe
c++filt.exe                   elfedit.exe           ld.bfd.exe          lldb-argdumper.exe   strings.exe
clang.exe                     find-all-symbols.exe  ld.exe              lldb-mi.exe          strip.exe
clang++.exe                   g++.exe               ld.gold.exe         lld-link.exe         widl.exe
clang-apply-replacements.exe  gcc.exe               ld.lld.exe          llvm-ar.exe          windmc.exe
clang-change-namespace.exe    gcc-ar.exe            libatomic-1.dll     llvm-lib.exe         windres.exe
clang-check.exe               gcc-nm.exe            libclang.dll        llvm-objdump.exe     x86_64-w64-mingw32-c++.exe
clang-cl.exe                  gcc-ranlib.exe        libgcc_s_seh-1.dll  llvm-ranlib.exe      x86_64-w64-mingw32-g++.exe
clang-format.exe              gcov.exe              libgfortran-3.dll   LTO.dll              x86_64-w64-mingw32-gcc.exe
clang-include-fixer.exe       gcov-tool.exe         libgomp-1.dll       mingw32-make.exe     x86_64-w64-mingw32-gcc-6.2.0.exe
clang-offload-bundler.exe     gdb.exe               libiomp5md.dll      modularize.exe       x86_64-w64-mingw32-gcc-ar.exe
clang-query.exe               gdborig.exe           liblldb.dll         nm.exe               x86_64-w64-mingw32-gcc-nm.exe
clang-rename.exe              gdbserver.exe         libomp.dll          objcopy.exe          x86_64-w64-mingw32-gcc-ranlib.exe
clang-reorder-fields.exe      gendef.exe            libquadmath-0.dll   objdump.exe          x86_64-w64-mingw32-gfortran.exe
clang-tidy.exe                genidl.exe            libssp-0.dll        ranlib.exe

5. Kommandozeile in C:\Temp geöffnet (dort befindet sich die hello.cpp):
MinGW-Modus von Clang (verwendet MinGW-Runtime):

C:\Temp>type hello.cpp
#include <iostream>

auto main() -> int
{
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

C:\Temp>c:\test\compiler\bin\clang++ -std=c++14 -ohello.exe hello.cpp

C:\Temp>hello.exe
Hello, World!

MSVC-Modus von Clang (verwendet MSVC-Runtime und Header. Habe Visual Studio 2015 installiert - Clang findet diese Pfade über VS-Umgebungsvariablen):

C:\Temp>c:\test\compiler\bin\clang-cl hello.cpp

C:\Temp>hello.exe
Hello, World!

Interessant ist, dass die aktuelle Version von Clang nicht mehr das -fms-compatibility-version -Flag benötigt. Man gibt sich dort also sehr wohl Mühe,
dass es "out-of-the-box" funktioniert (für clang-cl mit installiertem VS braucht man auch kein MinGW, das sollte eigentlich direkt aus dem installierten Order laufen).

Ich schlage vor du ersparst dir den weiteren Ärger und machst es einfach so wie hier von mir beschrieben

Gruss,
Finnegan

P.S.: Mir fällt gerade auf dass ich einen Dev-Snapshot der nächsten Clang-Version verwendet habe. Ich sehe aber keinen Grund, weshalb das mit früheren Versionen
nicht exakt so funktioneren sollte (meine Version die ich installiert hatte war schliesslich 3.8, und auch dort funktioniert es so wie von mir beschrieben).
Schlimmstenfalls benötigst du für den MSVC-Modus von Clang eben noch das -fms-compatibility-version -Flag (das braucht man übrigens nur für en MSVC-kompatiblem Modus!
War etwas irritiert über deinen Post mit diesem Flag und MinGW-Pfaden - da war wohl etwas grundlegend verwurstelt!).

Mein MinGW ist x86_64-6.2.0-posix-seh-rt_v5-rev1 und mein Clang ist LLVM-3.9.0-win64.exe von hier.

Nun habe ich deine Liste beinahe 1:1 angewendet (ausser, dass ich alles vom LLVM-Ordner in den mingw64-Unterordner kopiert habe, statt ein neues Verzeichnis "Compiler" für beide zu erstellen). Dazu hab ich alles Alte deinstalliert / gelöscht und sowohl MinGW als auch Clang (Snapshot, so wie du) neu heruntergeladen. Hier die Ausgabe. Dann nochmals mit Clang 3.9.0 Stable die selbe Leier: Ausgabe.

Finnegan

klanger schrieb:

Mein MinGW ist x86_64-6.2.0-posix-seh-rt_v5-rev1 und mein Clang ist LLVM-3.9.0-win64.exe von hier.

Nun habe ich deine Liste beinahe 1:1 angewendet (ausser, dass ich alles vom LLVM-Ordner in den mingw64-Unterordner kopiert habe, statt ein neues Verzeichnis "Compiler" für beide zu erstellen). Dazu hab ich alles Alte deinstalliert / gelöscht und sowohl MinGW als auch Clang (Snapshot, so wie du) neu heruntergeladen. Hier die Ausgabe. Dann nochmals mit Clang 3.9.0 Stable die selbe Leier: Ausgabe.

Hi. Hab mir das auch bei mir hier nochmal genauer angesehen.
Lass dir mal in der clang++ -Kommandozeile mit dem Flag -v genau ausgeben was er macht, vor allem auch welches für "target" er kompiliert.
Ich war nämlich gerade erstaunt dass die 4.0er-version von clang++ hier scheinbar doch für das MSVC-Target kompilert, wenn ich -target=XXX nicht explizit angebe:

C:\Temp>clang++ -v -std=c++14 -ohello.exe hello.cpp
clang version 4.0.0 (trunk)
Target: i686-pc-windows-msvc
Thread model: posix
...
#include "..." search starts here:
#include <...> search starts here:
 C:\test\compiler\bin\..\lib\clang\4.0.0\include
 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
 C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\ucrt
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\shared
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\um
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\winrt

Das ist natürlich nicht das was ich möchte
Clang ist allerdings ein Cross-Compiler, und man kann ihm explizit angeben, für welches Zielsystem man bauen möchte (das beinhaltet auch die Ziel-Runtime wie MinGW oder MSVC):

C:\Temp>clang++ -v --target=x86_64-w64-mingw32 -std=c++14 -ohello.exe hello.cpp
clang version 4.0.0 (trunk)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:\test\compiler\bin

...

clang -cc1 version 4.0.0 based upon LLVM 4.0.0-r282394 default target i686-pc-windows-msvc
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++\x86_64-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++\backward"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++\6.2.0"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++\6.2.0\x86_64-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32\include\c++\6.2.0\backward"
ignoring nonexistent directory "C:\test\compiler\include\c++\6.2.0"
ignoring nonexistent directory "C:\test\compiler\include\c++\6.2.0\x86_64-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\include\c++\6.2.0\backward"
ignoring nonexistent directory "C:\test\compiler\x86_64-w64-mingw32/sys-root/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 C:\test\compiler\lib\gcc\x86_64-w64-mingw32\6.2.0\include\c++
 C:\test\compiler\lib\gcc\x86_64-w64-mingw32\6.2.0\include\c++\x86_64-w64-mingw32
 C:\test\compiler\lib\gcc\x86_64-w64-mingw32\6.2.0\include\c++\backward
 C:\test\compiler\bin\..\lib\clang\4.0.0\include
 C:\test\compiler\lib\gcc\x86_64-w64-mingw32\6.2.0\include
 C:\test\compiler\lib\gcc\x86_64-w64-mingw32\6.2.0\include-fixed
 C:\test\compiler\x86_64-w64-mingw32\include
 C:\test\compiler\include
End of search list.

...

C:\Temp>hello.exe
Hello, World!

Das sieht schon besser aus und funkioniert ebenfalls!

Interessanterweise kann ich den selben Fehler wie bei dir provozieren, wenn ich für 32bit kompiliere:

C:\Temp>clang++ -v --target=i686-w64-mingw32 -std=c++14 -ohello.exe hello.cpp
clang version 4.0.0 (trunk)
Target: i686-w64-windows-gnu
Thread model: posix
InstalledDir: C:\test\compiler\bin

...

clang -cc1 version 4.0.0 based upon LLVM 4.0.0-r282394 default target i686-pc-windows-msvc
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++\i686-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++\backward"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++\"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++\\i686-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include\c++\\backward"
ignoring nonexistent directory "C:\test\compiler\include\c++\"
ignoring nonexistent directory "C:\test\compiler\include\c++\\i686-w64-mingw32"
ignoring nonexistent directory "C:\test\compiler\include\c++\\backward"
ignoring nonexistent directory "include\c++"
ignoring nonexistent directory "include\c++\i686-w64-mingw32"
ignoring nonexistent directory "include\c++\backward"
ignoring nonexistent directory "include"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32/sys-root/mingw/include"
ignoring nonexistent directory "include-fixed"
ignoring nonexistent directory "C:\test\compiler\i686-w64-mingw32\include"
#include "..." search starts here:
#include <...> search starts here:
 C:\test\compiler\bin\..\lib\clang\4.0.0\include
 C:\test\compiler\include
End of search list.
hello.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^
1 error generated.

Was auch nicht verwunderlich ist - schliesslich habe ich nur MinGW für x86_64-w64-mingw32 installiert. Du solltest also prüfen, ob deine Installation nicht per default fürs "i686"-Target kompiliert
(bei mir tut sie das: "based upon LLVM 4.0.0-r282394 default target i686-pc-windows-msvc").
Für "i686" ist ja schliesslich keine MinGW-Runtime da - Ordner wie z.B. lib\gcc\i686-w64-mingw32\6.2.0\include\c++\i686-w64-mingw32 fehlen, daher findet er auch die Header der Standardbibliothek nicht.

Also: Explizit x64/MinGW-Target angeben, und/oder MinGW auch für i686-Target installieren.

In meiner selbstgebauten Vesion habe ich diese ebenfalls in eine einzige Verzeichnisstruktur zusammengepackt:
Programme ohne Präfix wie "gcc.exe" gehören zur "Default"-Toolchain für das System (x64-Target, das sind die exakt selben Programme wie mit Target-Präfix, z.B. "x86_64-w64-mingw32-gcc.exe").
Daneben existieren dann noch die Programme mit "i686-w64-mingw32"-Präfix und ihre entsprechenden Ordner im Wurzelverzeichnis von MinGW. Dort wird dann auch Clang die Header-Dateien und libs suchen.

Finnegan

P.S.: Bei meinem selbstgebauten Clang ist mir das mit dem "default target" nicht aufgefallen, da ich dort Clang so konfiguriert habe,
dass er ohnehin 64bit-MinGW verwendet: "... default target x86_64-w64-windows-gnu"

Hey, danke, das war das Problem.
Das Target sollte man auch mit --version sehen, wie oben in den Screenshots. Beim 3.9.0 stable release bekam ich ja auch x86_64-pc-windows-msvc , was mich zwar ein wenig verwundert hat, aber wenn das so kommt, wenn man es frisch installiert ohne etwas zu ändern, dann wird das wohl stimmen so, dacht' ich...
Nun mit --target=x86_64-w64-mingw32 ist das Target (korrekterweise) x86_64-w64-windows-gnu und die Pfade stimmen nun auch endlich. Ausgabe:

PS C:\Windows\system32> cd /test
PS C:\test> get-content main.cxx
#include <iostream>

int main()
{
        std::cout << "Hello World!\n";
}
PS C:\test> clang++ --target=x86_64-w64-mingw32 main.cxx
PS C:\test> .\a.exe
Hello World!

Danke, dass du dir die Zeit genommen hast.

Finnegan schrieb:

P.S.: Bei meinem selbstgebauten Clang ist mir das mit dem "default target" nicht aufgefallen, da ich dort Clang so konfiguriert habe,
dass er ohnehin 64bit-MinGW verwendet: "... default target x86_64-w64-windows-gnu"

Kann ich das auch erreichen, ohne Clang selbst neu kompilieren zu müssen?

Finnegan

klanger schrieb:

Danke, dass du dir die Zeit genommen hast.

Jo gern. Vielleicht fragst du das nächste mal jedoch besser nach konkreten Lösungsvorschlägen für dein Problem. Dein Eingangsposting war ja eher ein "Rant" ohne eine konkrete
Frage - du hast Glück dass ich mich in dieser Frustration wiedererkannt habe, weil ich diese Phase auch schon hinter mir habe - nicht selten werden solche Postings nicht ganz unberechtigt einfach ignoriert ;).
Viele dieser fixen Verzeichnisstrukturen stammen aus der Linux/Unix-Welt und machen natürlich manchmal Probleme, wenn man das Programm unter Windows verwenden will.
Diese vorgegebenen Verzeichnisse können aber auch durchaus vorteilhaft sein - mit vielen komplexen Konfigurationsdateien kann man auch schnell im Chaos versinken.

klanger schrieb:

Finnegan schrieb:

P.S.: Bei meinem selbstgebauten Clang ist mir das mit dem "default target" nicht aufgefallen, da ich dort Clang so konfiguriert habe,
dass er ohnehin 64bit-MinGW verwendet: "... default target x86_64-w64-windows-gnu"

Kann ich das auch erreichen, ohne Clang selbst neu kompilieren zu müssen?

Unwahrscheinlich. Letzendlich ist das Default Target höchstwahrscheinlich ein fest einkompiliertes #define . Nimm das einfach in deine Compiler-Flags
auf - spätestens wenn man irgendwann für andere Systeme (Cross-)kompiliert muss man das ohnehin immer angeben.

Finnegan