Clang on Windows targeting gcc requirements

For either the latest clang built from souce on Windows or a binary distribution of clang on Windows it appears that clang expects the supporting gcc include files and lib files to be in the hardcoded directory:

c:\mingw

and follow the mingw directory structure.

1) Can this please be changed in the future so that some environment variable ( maybe CLANG_GCC ) can be set to the gcc installation rather than use a hardcoded path ?

2) Can clang be updated to support the mingw-64 directory structure and not just the mingw directory structure ? The mingw-64 distros seem now to be the preferred gcc distributions on Windows and support the latest versions of gcc.

Do I need to make these suggestions on the clang bug tracker for the suggestions to be seriously considered ?u

See http://reviews.llvm.org/D5268

See http://reviews.llvm.org/D5268
<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=&gt;

I don't understand what the above link means, or how it is connected to my suggestions below.

It’s an uncommitted patch teaching clang to support the mingw-64 directory structure instead of the hardcoded c:\mingw.

It's an uncommitted patch teaching clang to support the mingw-64
directory structure instead of the hardcoded c:\mingw.

Why is it "uncommitted" and not a part of clang source ?

What does supporting mingw-64 have to do with the hardcoded path c:\mingw ?

I do not understand how one obtains a patch from the link given, how one applies the patch, and to what the patch is supposed to be applied ( but I assume the patch is applied to the clang source somewhere ).

Why is it "uncommitted" and not a part of clang source ?

Because it hasn't been reviewed.

What does supporting mingw-64 have to do with the hardcoded path c:\mingw ?

Clang driver has no official support for mingw. Just a bunch of hardcoded
paths in the current driver. They break whenever new version of mingw is
released as version numbers are hardcoded as well. They also don't work for
mingw-w64 which as far as I know is more active than the original mingw
project.

I do not understand how one obtains a patch from the link given, how one
applies the patch, and to what the patch is supposed to be applied ( but I
assume the patch is applied to the clang source somewhere ).

Download raw diff will give you a patch file. You apply it to your local
clang directory.

    Why is it "uncommitted" and not a part of clang source ?

Because it hasn't been reviewed.

Does it normally take 9 months or more to review a fix ?

    What does supporting mingw-64 have to do with the hardcoded path
    c:\mingw ?

Clang driver has no official support for mingw. Just a bunch of
hardcoded paths in the current driver. They break whenever new version
of mingw is released as version numbers are hardcoded as well.

The hardcoded paths clang currently uses all appear to be off of c:\mingw.

It does not appear to be the case that version numbers are hardcoded. I can test the clang binaries for clang-3.4.1, clang-3.5.2, clang-3.6.1, and the latest clang-3.7 built from source all against the latest mingw distribution, which uses gcc-4.8.1, and is linked to from c:\mingw without any problems. If each clang release hardcoded the mingw version, by which I am guessing you mean of course the gcc version, it is doubtful that all the different clang releases I mentioned would work with the gcc-4.8.1 release.

If this fix removes the hardcoded c:\mingw path when searching for a gcc distro to use, how does the end-user tell clang where the gcc distro he wants to use with clang resides ?

They also
don't work for mingw-w64 which as far as I know is more active than the
original mingw project.

I would be glad if this patch fixes that problem, since the latest mingw-64 gcc release is gcc-5.1.

    I do not understand how one obtains a patch from the link given, how
    one applies the patch, and to what the patch is supposed to be
    applied ( but I assume the patch is applied to the clang source
    somewhere ).

Download raw diff will give you a patch file. You apply it to your local
clang directory.

I gather then that the patch file is a subversion patch file. From where in the llvm tree do I apply the patch ? How do I know that the patch will work with the latest llvm/clang source I have updated from the llvm/clang sunversion repositories ? Or is the patch only valid for a particular version of clang and not the latest version from source ?

Does it normally take 9 months or more to review a fix ?

Normally no, but not many people are interested in mingw which is why we
don't have proper driver support in the first place. People who review are
pretty busy so it's patch authors responsibility to remind them, it's
unfortunate but we've had many patches lost this way. I send pings every
week or so for my patches that go unreviewed.

The hardcoded paths clang currently uses all appear to be off of c:\mingw.

It does not appear to be the case that version numbers are hardcoded. I
can test the clang binaries for clang-3.4.1, clang-3.5.2, clang-3.6.1, and
the latest clang-3.7 built from source all against the latest mingw
distribution, which uses gcc-4.8.1, and is linked to from c:\mingw without
any problems. If each clang release hardcoded the mingw version, by which I
am guessing you mean of course the gcc version, it is doubtful that all the
different clang releases I mentioned would work with the gcc-4.8.1 release.

Have a look at InitHeaderSearch.cpp, it has a list of mingw versions, and
as you point out paths start with c:/mingw

If this fix removes the hardcoded c:\mingw path when searching for a gcc
distro to use, how does the end-user tell clang where the gcc distro he
wants to use with clang resides ?

I can't answer this one.

I gather then that the patch file is a subversion patch file. From where
in the llvm tree do I apply the patch ? How do I know that the patch will
work with the latest llvm/clang source I have updated from the llvm/clang
sunversion repositories ? Or is the patch only valid for a particular
version of clang and not the latest version from source ?

It's either svn or git patch, you're supposed to apply it to clang
checkout/clone. That would be llvm/tools/clang for a usual in-tree setup.
As with any other patch, it was generated from specific source version, but
since this code doesn't change too much you should be able to apply it
cleanly to trunk with a little bit of luck.

If you'd like to get this checked in, email patch authors, give hand
testing/reviewing the patch and try to get things rolling, it's been a
while since last comment in the review.

    Does it normally take 9 months or more to review a fix ?

Normally no, but not many people are interested in mingw which is why we
don't have proper driver support in the first place.

It does not sound like clang on Windows targeting gcc is very important to clang. That's a shame because clang on Windows targeting VC++ has no priority on Boost and only clang on Windows targeting gcc gets Boost testing. The main reason for that, as I have pointed out in the past, is that Boost PP library can't be bothered trying to emulate clang's version of VC++'s broken preprocessor, whereas clang on Windows targeting gcc provides a C++ standard conforming preprocessor.

People who review
are pretty busy so it's patch authors responsibility to remind them,
it's unfortunate but we've had many patches lost this way. I send pings
every week or so for my patches that go unreviewed.

    The hardcoded paths clang currently uses all appear to be off of
    c:\mingw.

    It does not appear to be the case that version numbers are
    hardcoded. I can test the clang binaries for clang-3.4.1,
    clang-3.5.2, clang-3.6.1, and the latest clang-3.7 built from source
    all against the latest mingw distribution, which uses gcc-4.8.1, and
    is linked to from c:\mingw without any problems. If each clang
    release hardcoded the mingw version, by which I am guessing you mean
    of course the gcc version, it is doubtful that all the different
    clang releases I mentioned would work with the gcc-4.8.1 release.

Have a look at InitHeaderSearch.cpp, it has a list of mingw versions,
and as you point out paths start with c:/mingw

I will look at it.

    If this fix removes the hardcoded c:\mingw path when searching for a
    gcc distro to use, how does the end-user tell clang where the gcc
    distro he wants to use with clang resides ?

I can't answer this one.

Perhaps the patch is only for support of mingw-64 as the gcc target but the reliance on c:\mingw remains. Support for mingw-64 is nevertheless a large step in the right direction since mingw-64 is the the mingw distro of choice for many Windows programmers using gcc. Linking c:\mingw to a mingw-64 distro is easy but it would really be better if there were some way to point to the mingw-64 distro you want to have clang use when invoking clang rather than relying on a hardcoded path.

    I gather then that the patch file is a subversion patch file. From
    where in the llvm tree do I apply the patch ? How do I know that the
    patch will work with the latest llvm/clang source I have updated
    from the llvm/clang sunversion repositories ? Or is the patch only
    valid for a particular version of clang and not the latest version
    from source ?

It's either svn or git patch, you're supposed to apply it to clang
checkout/clone.

Does llvm/clang have a git interface ? I assumed that subversion is still being used. I have found that git is a more flexible SCCS than subversion but the latter is still quite usable.

That would be llvm/tools/clang for a usual in-tree
setup. As with any other patch, it was generated from specific source
version, but since this code doesn't change too much you should be able
to apply it cleanly to trunk with a little bit of luck.

I will checkout a separate version of the latest llvm/clang to try it out. I don't like messing up my normal clang source build on Windows by applying patches and then worrying that each new update to llvm/clang is going to conflict with a patch.

If you'd like to get this checked in, email patch authors, give hand
testing/reviewing the patch and try to get things rolling, it's been a
while since last comment in the review.

I will do my best but I am really surprised that the clang/Windows/gcc version of clang doesn't get much attention among clang development.

Adding back cfe-dev

I don't know where Paul Bristow's comments are coming from ( I don't see them in this mailing list recently anywhere ) but he has recently attempted to get clang on Windows targeting gcc working and has gotten help for it on the Boost developers mailing list.

I just want to concur with his assertion that having the ability to use a mingw-64 distro, rather than just a mingw distro, is important for Boost testing using clang on Windows. Also the issue of hardcoded locations for clang on Windows targeting gcc, while not as important, seems like an issue that clang developers could solve either through some command-line parameter or environment variable.

I still don't know why users of clang are expected to step up to get these issues addressed. Don't clang developers consider this an issue of any importance ? Last I heard Windows was still be used vastly more than Linux and/or Mac combined in the world. I also use Linux and have no prejudices against it, but like many developers find Windows more developer friendly overall.

Unlike Paul I do understand why clang uses gcc's headers and RTL ( aka libstdc++ ). What I have always failed to understand is why, this being the case, clang has so little documentation on the relationship of any particular clang release to the particular underlying gcc releases with which clang can work. Similarly, as I understand it, clang can use libc++ instead of libstdc++. But again under Windows there is no documentation on how this may be done. In general the porting of clang to Windows, while working fine if everything is setup correctly, seems like almost an afterthought for clang developers.

I don't know where Paul Bristow's comments are coming from ( I don't see
them in this mailing list recently anywhere ) but he has recently attempted
to get clang on Windows targeting gcc working and has gotten help for it on
the Boost developers mailing list.

He replied only to my email and didn't include cfe-dev.

I still don't know why users of clang are expected to step up to get these
issues addressed. Don't clang developers consider this an issue of any
importance ? Last I heard Windows was still be used vastly more than Linux
and/or Mac combined in the world. I also use Linux and have no prejudices
against it, but like many developers find Windows more developer friendly
overall.

I'm starting to repeat myself, there's no "clang developers" in the sense
you understand. There's people employed by companies and paid to work on
stuff those companies find important. Chromium team cares about Windows
support the most and as far as I know they're the main contributors for
VC++ ABI stuff. The open source community (clang developers) would love to
have Clang working seamlessly on Windows but haven't had the time to
address it. There needs to be someone to drive this effort and we don't
really have that someone right now. So whoever finds these issues important
can either step up or wait for someone else to get this done, when and if
they get to it.

Unlike Paul I do understand why clang uses gcc's headers and RTL ( aka
libstdc++ ). What I have always failed to understand is why, this being the
case, clang has so little documentation on the relationship of any
particular clang release to the particular underlying gcc releases with
which clang can work. Similarly, as I understand it, clang can use libc++
instead of libstdc++. But again under Windows there is no documentation on
how this may be done. In general the porting of clang to Windows, while
working fine if everything is setup correctly, seems like almost an
afterthought for clang developers.

We went through this documentation issue in the other thread. As for libc++
on Windows, it's not much different from anything else, it's not officially
supported because nobody cared enough to get it working. There's been a few
efforts, you can search the mailing list, I don't know the exact details, I
think someone recently asked about it.

See http://reviews.llvm.org/D5268
<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D5268&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=YgSrUuiAhPt76cF_h_LXb8Mg84W8p9nMvUiL3koHKP4&s=aW_6t6KDGfo5hO6NiTn5Hy9afNhzwfkX-BZHT9PtXmk&e=&gt;

I can see that the patch has been applied officially to the latest clang source. It's in the latest code when I update llvm/clang. Thanks very much !

But how do I use it ?

Am I supposed to be able to build clang using a mingw-64 distro in my PATH ?

When I compile with clang how do I tell it to use the mingw-64 headers and RTL ? Does it matter whether the mingw-64 distro is 32 bit or 64 bit ?

Do I need to have the mingw-64 distro at c:\mingw ?

I am willing to test this for clang and report back results here, since I can easily switch between mingw-64 distros ( 4.8.4, 4.9.2, 5.1 ) and I test a number of Boost libraries including my own with clang, but I need a little information on how to do it.

You only need to have the bin directory in your PATH. clang will find the include and library directory based on the bin directory. There are no fixed paths, you can put in c:\mingw or wherever.

It works by looking for 'gcc' on PATH and then assuming that it is in the
bin directory of a mingw installation. It will back out of that directory
and look relative to it for headers and libraries. Will that work?

You only need to have the bin directory in your PATH. clang will find
the include and library directory based on the bin directory. There are
no fixed paths, you can put in c:\mingw or wherever.

Perfect. I will test it out.

Excellent ! I will try it out and report back any problems I may find. Hopefully there will be none and clang/mingw-64/gcc on Windows will be a reality. That will make using clang on Windows targeting gcc much better as mingw-64 distros are better than mingw distros in many ways, especially in Windows API support. Although my own Boost libraries are not involved in Windows API a number of Boost libraries are so testing them with clang should be easier when mingw-64 is used.

I’ve used to build clang on MSYS2 with older version of this patch at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/clang-mingw-driver.patch and it served me well. this new patch not so much.Below the relevant dumps ;

$ g++ -E -x c++ - -v < /dev/null
Using built-in specs.
COLLECT_GCC=C:\msys2_64\mingw64\bin\g++.exe
Target: x86_64-w64-mingw32
Configured with: …/gcc-4.9.2/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/4.9.2 --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-cloog-backend=isl --enable-version-specific-runtime-libs --disable-cloog-version-check --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-cloog=/mingw64 --with-pkgversion=‘Rev5, Built by MSYS2 project’ --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.9.2 (Rev5, Built by MSYS2 project)
COLLECT_GCC_OPTIONS=‘-E’ ‘-v’ ‘-shared-libgcc’ ‘-mtune=generic’ ‘-march=x86-64’
C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/cc1plus.exe -E -quiet -v -iprefix C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/ -D_REENTRANT - -mtune=generic -march=x86-64

1 “”

1 “”

1 “”

1 “”

ignoring duplicate directory “C:/msys2_64/mingw64/lib/gcc/…/…/lib/gcc/x86_64-w64-mingw32/4.9.2/include”
ignoring nonexistent directory “C:/msys64/mingw64/include”
ignoring nonexistent directory “/mingw64/include”
ignoring duplicate directory “C:/msys2_64/mingw64/lib/gcc/…/…/lib/gcc/x86_64-w64-mingw32/4.9.2/include-fixed”
ignoring duplicate directory “C:/msys2_64/mingw64/lib/gcc/…/…/lib/gcc/x86_64-w64-mingw32/4.9.2/…/…/…/…/x86_64-w64-mingw32/include”
ignoring nonexistent directory “C:/msys64/mingw64/x86_64-w64-mingw32/include”
#include “…” search starts here:
#include <…> search starts here:
C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/include
C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/…/…/…/…/include
C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/include-fixed
C:/msys2_64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.9.2/…/…/…/…/x86_64-w64-mingw32/include
C:/msys2_64/mingw64/lib/gcc/…/…/include/c++/4.9.2
C:/msys2_64/mingw64/lib/gcc/…/…/include/c++/4.9.2/x86_64-w64-mingw32
C:/msys2_64/mingw64/lib/gcc/…/…/include/c++/4.9.2/backward

Built with the older MSYS2 patch ;

$ clang++ -E -x c++ - -v < /dev/null
clang version 3.7.0 (http://llvm.org/git/clang.git e7cee814a12b5dd16c8672543fd93efe741d5208) (http://llvm.org/git/llvm.git d594ba081506f0f57e9801e3f81467b1766b1e04)
Target: x86_64-pc-windows-gnu
Thread model: posix
“C:\msys2_64\mingw64\bin\clang++.exe” -cc1 -triple x86_64-pc-windows-gnu -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -fno-unique-section-names -resource-dir “C:\msys2_64\mingw64\bin\…\lib\clang\3.7.0” -internal-isystem “C:\msys2_64\mingw64\bin/…/include/c++/4.9.2” -internal-isystem “C:\msys2_64\mingw64\bin/…/include/c++/4.9.2/x86_64-w64-mingw32” -internal-isystem “C:\msys2_64\mingw64\bin/…/include/c++/4.9.2/backward” -internal-isystem “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++” -internal-isystem “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++/x86_64-w64-mingw32” -internal-isystem “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++/backward” -internal-isystem “C:\msys2_64\mingw64\bin\…\lib\clang\3.7.0\include” -internal-isystem “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include” -internal-isystem “C:\msys2_64\mingw64\bin/…/include” -fdeprecated-macro -fdebug-compilation-dir “E:\llvm\buildmingw64\bin” -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o - -x c++ -
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target x86_64-pc-windows-gnu
ignoring nonexistent directory “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++”
ignoring nonexistent directory “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++/x86_64-w64-mingw32”
ignoring nonexistent directory “C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include/c++/backward”
ignoring duplicate directory “C:\msys2_64\mingw64\bin..\lib\clang\3.7.0\include”
#include “…” search starts here:
#include <…> search starts here:
C:\msys2_64\mingw64\bin/…/include/c++/4.9.2
C:\msys2_64\mingw64\bin/…/include/c++/4.9.2/x86_64-w64-mingw32
C:\msys2_64\mingw64\bin/…/include/c++/4.9.2/backward
C:\msys2_64\mingw64\bin..\lib\clang\3.7.0\include
C:\msys2_64\mingw64\bin/…/x86_64-w64-mingw32/include
C:\msys2_64\mingw64\bin/…/include
End of search list.

New Patch

$ ./clang++ -E -x c++ - -v < /dev/null
clang version 3.7.0 (http://llvm.org/git/clang.git 0af047c817acbc67e61aa82f0b43a54d61b753f8) (http://llvm.org/git/llvm.git 9a9ee6f550c0789053c260203aea8430a34554fe)
Target: x86_64-pc-windows-gnu
Thread model: posix
“E:\llvm\buildmingw64\bin\clang++.exe” -cc1 -triple x86_64-pc-windows-gnu -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -resource-dir “E:\llvm\buildmingw64\bin\…\lib\clang\3.7.0” -internal-isystem “C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++” -internal-isystem “C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++\x86_64-w64-mingw32\” -internal-isystem “C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++\backward” -internal-isystem “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++” -internal-isystem “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++\x86_64-w64-mingw32\” -internal-isystem “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++\backward” -internal-isystem “E:\llvm\buildmingw64\bin\…\lib\clang\3.7.0\include” -internal-isystem “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include” -internal-isystem “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include-fixed” -internal-isystem “C:\msys2_64\mingw64\x86_64-w64-mingw32\include” -internal-isystem “C:\msys2_64\mingw64\include” -fdeprecated-macro -fdebug-compilation-dir “E:\llvm\buildmingw64\bin” -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o - -x c++ -
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target x86_64-pc-windows-gnu
ignoring nonexistent directory “C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++”
ignoring nonexistent directory "C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++\x86_64-w64-mingw32"
ignoring nonexistent directory “C:\msys2_64\mingw64\x86_64-w64-mingw32\include\c++\backward”
ignoring nonexistent directory “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++”
ignoring nonexistent directory "C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++\x86_64-w64-mingw32"
ignoring nonexistent directory “C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include\c++\backward”
#include “…” search starts here:
#include <…> search starts here:
E:\llvm\buildmingw64\bin..\lib\clang\3.7.0\include
C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include
C:\msys2_64\mingw64\lib\gcc\x86_64-w64-mingw32\4.9.2\include-fixed
C:\msys2_64\mingw64\x86_64-w64-mingw32\include
C:\msys2_64\mingw64\include
End of search list.

I assume this patch only meant to fix the official mingw-builds?

You only need to have the bin directory in your PATH. clang will find
the include and library directory based on the bin directory. There are
no fixed paths, you can put in c:\mingw or wherever.

Everything is working fine so far. I was able to build the latest clang from source successfully using mingw-64/gcc-5.1 and I have been invoking clang successfully so far with the mingw-64/gcc-5.1 implementation in my PATH. Great job you did getting the patch into the official clang source, and I really appreciate it ! Being able to use clang with mingw-64 RTL as well as the mingw RTL is a real plus for using clang on Windows.

I have also noticed a monumental speedup in the clang compilation process using mingw-64 as opposed to mingw. Whatever the reason it is most welcome.

Hi Hurcan,

clang support the mingw-builds and mingw.org directory structure.
With the msys2 build, the problem is the missing C++ include directories?

Yaron