- Revert the addition of CLANG_SYSTEM_LIBARIES and LLVM_SYSTEM_LIBRARIES
- Change addCMakeLibraryList to parse non-absolute path .lib dependencies as system libraries
On some systems (esp. systems that use unique hashed file-paths for
library-versions like Nix), we can't expect LLVM and Clang to share
lib/bin directories.
The best we can do is find the matching clang libraries in the
CMAKE_LIBRARY_PATH provided by the environment
This change relaxes the restriction added in the prior commit that LLD
should be alongside LLVM.
This also leaves unresolved the issue of making sure the link mode
(static or shared) of LLD matches that of LLVM/Clang. That would be an
unfortunate restriction, since LLD seems to be provided only as a static
lib on some distros.
This commit reworks the LLVM/Clang/LLD discovery process for CMake. The
biggest changes are that:
1. We search for LLVM from most preferred directory to least, skipping
any `llvm-config` that is the wrong version, or that doesn't
support the requested link mode ("static" or "shared").
2. `ZIG_PREFER_CLANG_CPP_DYLIB` has been renamed to `ZIG_SHARED_LLVM`,
to better align with `ZIG_STATIC_LLVM`.
3. We only search for LLVM in the same directory alongside LLVM.
4. LLVM's link mode is forwarded to Clang, so that we can look for the
appropriate shared/static libraries.
5. We use `--link-static` when querying `--system-libs` from llvm-config,
so that this will include libz and other dependencies for
statically linking LLD
CMake has a surprising default behavior where looking up a library by
multiple names gives the name order higher priority than the directory
search order.
For example, if your system provides "llvm-config-14" and
CMAKE_PREFIX_PATH includes "llvm-config", CMake will always end up
choosing the system-provided llvm-config-14.
This change add NAMES_PER_DIR to request the more sensible behavior:
directory search order has higher priority than name order, so
CMAKE_PREFIX_PATH always wins over system-provided tools/libraries.
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.
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`.
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.
