Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
This reverts commit 64effa9a71.
It turns out that the LLD handling of the TLS data structures
("_tls_used" and "_tls_index") needs more work, causing the
arm64ec side of arm64x binaries to not get them hooked up properly.
Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
If not building with FULL_LLVM the directory is empty or doesn't exist.
Otherwise it contains the LLVM headers. In either case merge the architecture specific ones into it.
We used to copy libc++ and libunwind, since those were needed
to actually run the toolchain - but others, like the asan runtime,
may be needed for the user to be able to run the executables that
are built. If this bin directory is in the user's $PATH, they should
be picked up automatically.
For distribution, and for architectures other than the default,
the user still needs to use the binaries from the arch specific
directories.
Jacek Caban