It is now possible to force linking with system linker `ld` instead
of the LLVM `lld` linker when building natively on the target. This
can be done at each stage by specifying `--system-linker-hack` flag,
and can be useful on platforms where `lld` fails to operate properly
such as macOS 11 Big Sur on ARM64 where every binary/dylib is expected
to be codesigned.
Some example invocations for each stage of compilation of Zig
toolchain:
```
cmake .. -DCMAKE_PREFIX_PATH=/path/to/llvm -DSYSTEM_LINKER_HACK=1
```
```
build/zig build test --system-linker-hack
```
```
build/zig build --prefix $(pwd)/stage2 -Denable-llvm
--system-linker-hack
```
```
build/zig build-exe hello.zig --system-linker-hack
```
This commit fixes linking issue on macOS 11 BigSur by appending
a prefix path to all lib and framework search paths known as
`-syslibroot`.
The reason this is needed is that in macOS 11, the system libraries
and frameworks are no longer readily available in the filesystem.
Instead, the new macOS ships with a built-in dynamic linker cache
of all system-provided libraries, and hence, when linking with either
`lld.ld64` or `ld64`, it is required to pass in `-syslibroot [dir]`.
The latter can usually be obtained by invoking `xcrun --show-sdk-path`.
With this commit, Zig will do this automatically when compiling natively
on macOS. However, it also provides a flag `-syslibroot` which can be
used to overwrite the automtically populated value.
To summarise, with this change, the user of Zig is not required to
generate and append their own syslibroot path. Standard invocations
such as `zig build-exe hello.zig` or `zig build` for projects will
work out of the box. The only missing bit is `zig cc` and `zig c++`
since the addition of the `-syslibroot` option would be a mismatch
between the values provided by `clang` itself and Zig's wrapper.
* std.fs.Dir.readFile: add doc comments to explain what it means when
the returned slice has the same length as the supplied buffer.
* introduce readSmallFile / writeSmallFile to abstract over the
decision to use symlink or file contents to store data.
with respect to std.builtin.link_libc.
The commit 27e008eb29 did not solve the
problem because although it got std.builtin.link_libc to be true for
compiler_rt.zig and c.zig, it had other unintentional side effects which
broke the build for -lc -target foo-linux-musl.
This commit introduces a new flag to Compilation to allow setting this
comptime flag to true without introducing other side effects to
compilation and linking.
This is convenient for debugging purposes, as well as simplifying the
caching system since executable basenames will not conflict with their
corresponding object files.
* change some {} to be {s} to gain type safety
* fix libraries being libfoo.lib instead of foo.lib for COFF
* when linking mingw-w64, add the "always link" libs so that we
generate DLL import .lib files for them as the linker code relies on.
* COFF LLD linker does not support -r so we do a file copy as an
alternative to the -r thing that ELF linking does.
I will file an issue for the corresponding TODO upon merging this
branch, to look into an optimization that possibly elides this copy
when the source and destination are both cache directories.
* add a CLI error message when trying to link multiple objects into one
and using COFF object format.
This cleans up how the CLI parses and handles -E, -S, and -c.
Compilation explicitly acknowledges when it is being used to do C
preprocessing.
-S is properly translated to -fno-emit-bin -femit-asm but Compilation
does not yet handle -femit-asm.
There is not yet a mechanism for skipping the linking step when there is
only a single object file, and so to make this work we have to do a file
copy in link.flush() to copy the file from zig-cache into the output
directory.
Normally when using LLD to link, Zig uses a file named "lld.id" in the
same directory as the output binary which contains the hash of the link
operation, allowing Zig to skip linking when the hash would be unchanged.
In the case that the output binary is being emitted into a directory which
is externally modified - essentially anything other than zig-cache - then
this flag would be set to disable this machinery to avoid false positives.
* Better defaults when using -fno-LLVM
* Fix compiler_rt and libc static libraries were getting a .zig
extension instead of .a extension.
* when using the stage1 backend, put the object file next to the
stage1.id file in the cache directory. this prevents an object file
from polluting the cwd when using zig from the CLI.
