This avoids having to manually add -lpsapi when linking in libc++.a.
This requires using a new script to merge libraries using ar -M
with a small MRI script.
The script merge_archives.py in libcxx does the merge by manually
extracting all object files and creating a new archive out of them.
The import libraries created by LLVM have more than one object file
with the same file name (just like MSVC tools do), so extracting
them doesn't work as intended - but merging using a MRI script works.
This is the correct layering/ordering.
This requies setting forcing CXX_SUPPORTS_CXX11=TRUE in cmake,
since it tries linking to see whether the C++ environment works,
but we haven't built libcxx yet.
Manually add the libcxx include directory to the include path
(since libunwind does use some C++ headers but doesn't require
linking to C++ libraries).
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.
This actually gets set by default by the installed config headers,
depending on how the libraries were configured.
Also, the -Xclang -flto-visibility-public-std workaround doesn't
seem to be necessary while building these test apps (but it might
potentially be necessary if building more complicated apps).
This requires manually enabling sjlj exceptions, since libunwind
doesn't support the other exception handling mechanisms on windows
(yet).
Don't enable exceptions on aarch64 yet, since no exception handling
mechanism is implemented for windows on aarch64 yet.
These versions contain fixes relevant to mingw/clang.
Do the svn rebase (only necessary for getting sensible llvm/clang
version numbers in clang --version) before checking out the specific
version, otherwise we always end up at the latest master version.
llvm and clang have got new patches that are relevant for mingw
and arm64/win.
compiler-rt has changed things, so we can't ask it to build builtins
for i686 any longer, but need to request it for i386 instead - and
clang will expect it to be named i386 even though we're invoking it
with an i686 target.
This has now been committed upstream in the master branch (we
check out the master branch of compiler-rt, not the 3.9 branch),
in SVN rev 287465 (git mirror commit 8134888c4d01).
The second one, for msvc mode (which vlc doesn't need anyway), isn't
necessary now that llvm has been patched to emit calls properly using
the msvc helper function names.
This fixes up handling of divisions on ARM/Windows, and consistently
does calls to helper functions using the windows/msvc names, instead
of the libgcc naming.
The 3.8 branch produces broken code for divisions on arm/windows.
The brokenness can appear as incorrect behaviour or crashes.
The 3.9 branch isn't released yet, but is probably a better target
to base any work on at the moment.
The previously existing patch needed some modifications to fit
on top of lld 3.9.
Patch 2 makes sure that one still can use the lld built in this
way for linking in MSVC mode.
Patch 3 fixes linking binaries larger than 4 MB or so (previously
the binaries linked fine but didn't work).
Patch 4 makes sure to error out if the relocations are too far
away (instead of producing a broken binary), which happens after
16 MB.
Patch 5 fixes relocations that have an offset, which probably
happens in hand-written assembly (in libav).
Patches 1 and 2 fix a bug (that has been present in 3.7 and 3.8)
where it can use the wrong instruction in some cases (libav
with inline assembly disabled), causing rounding errors in
integer audio dct's there.
Patch 3 allows building inline assembly with clang/llvm in MSVC mode.
Patches 1-2 are just rebased from the earlier version for clang
3.8, no changes in surrounding code there.
Patch 3 is necessary to fix a regression in assembling standalone
assembly files in 3.9.
Patch 4 makes clang work in MSVC mode with the MSVC SDK for ARM
(to simplify testing of the toolchain in that mode).
Martin Storsjö