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.
This allows non-msys build systems to use the triplet prefixed
compiler frontends on windows.
Keep the old shell script version as well, for easier hackability
on unix platforms.
For x86 architectures, binutils objcopy and strip can be used as
such.
For armv7 and aarch64, binutils doesn't recognize the architectures
and refuse to touch the files. For most/everything that objcopy/strip
do, the actual architecture doesn't really matter though. Therefore,
provide a wrapper script and a minimal tool for editing PE executables,
that change the architecture from armv7 and aarch64 to i686 and x86_64
respectively before invoking binutils, and change it back afterwards.
In case the binutils tools are missing, just return a successful result
without doing anything for stripping operations (previously, we had the
<triplet>-strip tool symlinked to /bin/true, so this isn't any worse than
before) and fail for other objcopy operations.
This fixes building resource files that refer to external files
relative to the source directory, without specifying any directory
via include flags to windres itself. This is needed since llvm-rc
doesn't see the original source file but only sees the preprocessed
one in a temporary directory.
Alternatively, the preprocessed file could be placed in the same
directory as the source file, but when building e.g. outside of the
source tree, writing files (even temporary ones) inside the source
tree isn't generally expected.
This avoids needing the clang++ symlink. On platforms without symlinks
(i.e. windows), clang.exe and clang++.exe are two separate but identical
executables. This allows getting rid of the latter, saving size.
This makes the output architecture independent, allowing
the x86_64 GNU binutils binary to be used for other
architectures as well, including arm/arm64 which aren't supported
by binutils.
Provide wrappers named <triplet>-gcc and <triplet>-g++ as well,
to ease cross compilation with e.g. autotools, to allow just
specifying --host=<triplet>.
Provide wrappers for objdump and ld that provide specific output
that autotools look for.
Provide <triplet>-strip as a symlink to /bin/true, since there is
no strip tool available yet (and llvm-objcopy doesn't support
COFF yet).
The MinGW CRT wrapping has a few minor issues that makes native
TLS fail at the moment.
LLVM doesn't support native TLS on windows/aarch64, but emulated
TLS is supported now.
Dwarf is also the default in clang on i686, but libunwind currently
has an issue relating to unwinding dwarf exceptions on i686 on
windows (and less easily reproducible on other platforms),
see https://reviews.llvm.org/D38680.
This enables exceptions on aarch64, where they previously were
avoided/disabled.
When linking to a statically linked libunwind with support for
dwarf, one (currently) has to link in -lpsapi.
Martin Storsjö