Conflicts:
* cmake/Findclang.cmake
* cmake/Findlld.cmake
* cmake/Findllvm.cmake
In master branch, more search paths were added to these files with "12"
in the path. In this commit I updated them to "13".
* src/stage1/codegen.cpp
* src/zig_llvm.cpp
* src/zig_llvm.h
In master branch, ZigLLVMBuildCmpXchg is improved to add
`is_single_threaded`. However, the LLVM 13 C API has this already, and
in the llvm13 branch, ZigLLVMBuildCmpXchg is deleted in favor of the C
API. In this commit I updated stage2 to use the LLVM 13 C API rather
than depending on an improved ZigLLVMBuildCmpXchg.
Additionally, src/target.zig largestAtomicBits needed to be updated to
include the new m68k ISA.
- On Intel Macs, the path is /usr/local/opt/llvm@12
- On Silicon Macs, the path is /opt/homebrew/opt/llvm@12
This makes specifying CMAKE_PREFIX_PATH optional for Homebrew LLVM.
More precisely, aac4fe380d16a957627af2d6e5110ee35ad7e7e7 which is the
current tip of release/13.x.
Immediately following commits are tracking the same LLVM version.
Previously, there was an option ZIG_PREFER_LLVM_CONFIG which would
override the default of not using llvm-config when cross compiling.
That option is now removed in favor of the more powerful
ZIG_USE_LLVM_CONFIG which defaults to OFF for cross compiling and ON for
native compilation. The option overrides the default.
This will be used in zig-bootstrap to improve support for native builds.
Conflicts:
cmake/Findllvm.cmake
The llvm11 branch changed 10's to 11's and master branch added the
"using LLVM_CONFIG_EXE" help message, so the resolution was to merge
these changes together.
I also added a check to make sure LLVM is built with AVR enabled, which
is no longer an experimental target.
This is helpful on systems with multiple LLVM installations.
For example, OpenBSD ships with LLVM in the base system, but without
support for extra targets.
A full LLVM version can be installed using the ports system, but even
when it is, `cmake` is not going to pick it up unless `/usr/local` is
explicitly added to the `cmake` search paths.
Having the full `llvm-config` path printed on error is helpful to
understand that the detected LLVM version was not the expected one.
Without this, building from source caused:
CommandLine Error: Option 'mc-relax-all' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
This is due to LLVM static libs compiled in multiple times. But without
the LLVM static libs on the linker line, it caused undefined symbol
linker errors.
So our hands are tied. Homebrew users will have to specify
`-DZIG_PREFER_CLANG_CPP_DYLIB`.
* don't unconditionally pass -lz3 for mingw builds. If mingw builds
require this then the llvm-config executable should put it as part of
--system-libs. If there is a bug and it does not do that, and we need
a workaround, then the workaround should be an explicit cmake option.
* don't link libstage2.a against -lntdll. This causes zig to set
`builtin.link_mode == .Dynamic` and include the TLS definitions,
which then collide with the mingw-w64 symbols. This should probably
be addressed separately, but for now this solves the problem and
there is no reason to link a static library against a DLL.
* Findllvm.cmake no longer treats the libraries as "optional" and will
emit a cmake error if one is not found. Additionally, the
not-required LLVM library LLVMTableGen is omitted.
Match package-name case from CMakeLists.txt .
New warning sample:
The package name passed to `find_package_handle_standard_args` (LLVM) does
not match the name of the calling package (llvm). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Rather than `zig0 build ...` the build now does
`zig0 build-lib ...`, avoiding the requirement of linking the build
script, and thus avoiding the requirement of finding native libc,
for systems where libc is the system ABI.
