clang_rt obscured about llvm-mingw

[mstorsjo]

clang_rt is the correct replacement for libgcc but it is not included with all the rest of the libraries

Neither is libgcc. While compiler_rt builtins are placed in <toolchain>/lib/clang/<clangversion>/lib/windows/libclang_rt.<arch>.a, libgcc is normally placed in e.g. <toolchain>/lib/gcc/<triplet>/<gccversion>/libgcc.a.

The difference lies in the fact that gcc refers to libgcc by adding that directory to the path by passing -L to the linker and then linking to it with -lgcc. Clang on the other hand refers to it with an absolute path to the static library. Upstream is reluctant to changing this even though it also has tripped up some other issues along the way, see https://reviews.llvm.org/D51440.

Also, I think it's worth making a FAQ or wiki so that others don't find this pitfall.

TBH, I don't really see the location of the compiler_rt library being a frequently asked question, as most users won't run into the issue as the compiler automatically adds the argument (unless you explicitly opt out of that with -nostdlib or -nodefaultlibs).

FWIW, libtool does a similar thing in certain cases (linking a shared library that contains C++ code), by first doing a test link using -v, parsing out all the automatically added libs from that, and then linking with -nostdlib and manually adding all the libs that the compiler otherwise would have added (possibly with some amount of filtering of them).

[GravisZro]

Strange but as long as they are on it, ok.

[mstorsjo]

Well, I wouldn't call it "on it" in the sense of actually working towards changing it; I see it more like clang upstream is (now) aware that this oddity is causing issues in certain cases, but regards is as "working as intended" and prefers that the kinks are worked around elsewhere. Wrt libtool, it's problematic as libtool upstream is very much stale and patches aren't really being processed and merged.