LLVM's OpenMP implementation only supports Windows on x86, and it
requires a MASM-compatible assembler to build it. Build UASM
for this purpose, for now. (UASM isn't available packaged in
debian/ubuntu repos.) In the future, llvm-ml should be able
to handle it instead, but it's not currently mature enough.
Not including it in the regular build-all.sh for now, as UASM
isn't generally available.
Passing -lucrt* to the clang driver inhibits the implicit default
-lmsvcrt, so this ends up only using libucrtapp.a instead of libucrt.a.
This still requires that the default crt was ucrt, as the prebuilt
libc++.a needs to have been built for the right crt.
Since clang 9.0.0 (34ec6929a1fb33716d0035dc0f1f164d7568b4dc
in llvm-project), it's no longer necessary to set this to be able
to use __cxa_thread_atexit (for TLS destructors). This brings the
behaviour closer to GCC, and reduces the amount of non-default
options used.
For build-mingw-w64.sh to succeed when installing to such a path,
the mingw-w64 version has to be updated to the latest git master.
build-mingw-w64-libraries.sh still fails in this case, as libtool
fails to properly quote $LD in a test for whether the linker is GNU ld.
This saves a lot of diskspace, when symlinks are turned into full
copies of the tools on windows, as the symlinks only point to a small
wrapper instead of to the full tool.
When adding the terminator without incrementing arg and checking for
overflows with "arg > max_arg", we need to allocate space for one
extra element for the implicit terminator.
This option seems to be used occasionally by projects to work around
various issues with popen in GNU windres.
Our windres wrapper always uses a temp file for the preprocessing
output, so for us the option is a no-op.
Convert paths with backslashes to forward slashes.
libtool tries to parse this output in order to find object files and
libraries that always should be linked in, but libtool can't handle
paths with backslashes (and quotes) which clang currently outputs.
This is a quick and ugly workaround until clang can be made to
output paths with forward slashes on windows, see
https://reviews.llvm.org/D53066 for progress on that matter.
If we try to do that, clang would end up calling <triplet>-gcc with the
same arguments. In our setup, this recursively ends up calling clang again,
ending up with infinite recursion.
We quote each passed through argument, and escape quote chars in them.
For cases when the passed through argument ends with a backslash, this
fails though, since whatever is unescaping it doesn't seem to handle
double backslashes for escaping backslashes themselves.
Martin Storsjö