- Revert the addition of CLANG_SYSTEM_LIBARIES and LLVM_SYSTEM_LIBRARIES
- Change addCMakeLibraryList to parse non-absolute path .lib dependencies as system libraries
This reverts commit 55c3efcb58.
This caused a regression when building Zig with Homebrew.
Also I don't like that it prints a message on success. Only when there
is a problem should an error message be printed.
closes#14093
build.zig: add a 'compile' step to compile the self-hosted compiler
without installing it.
Compilation: set cache mode to whole when using the LLVM backend and
--enable-cache is passed.
This makes `zig build` act the same as it does with stage1. Upside is
that a second invocation of `zig build` on an unmodified source tree
will avoid redoing the compilation again. Downside is that it will
proliferate more garbage in the project-local cache (same as stage1).
This can eventually be fixed when Zig's incremental compilation is more
robust; we can go back to having LLVM use CacheMode.incremental and rely
on it detecting no changes and avoiding doing the flush() step.
This is a simplification of the cmake build script which introduces a
new "stage3" target that is built by default, which builds and installs
a stage3 zig.
It greatly simplifies the build instructions for Zig, making it conform
to the regular cmake routine, while still producing a stage3 artifact.
If you have multiple llvm-config executables in your path, and all of
them cause failures, then only the last failure will be printed. This
can cause confusion when the multiple llvm-config executables are from
different major LLVM versions, i.e. LLVM 13 and 14, which might mask an
error that happened on the LLVM 14 llvm-config with an unrelated error.
This commit makes it so that all errors are collected into a list and
printed all at once; this way, you can see how each llvm-config
executable failed to configure properly. Note that the failures still
won't be printed if a successful configuration is found.
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.
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`.
