Previously, I have incorrectly assumed that with two-level namespace
we only need to link in dylibs/frameworks that actually export symbols
which are undefined in the linked image. Turns out, regardless of
whether we link with two-level namespace (default on macOS) or a
flat namespace (more common on other platforms), we always need to
put the dylibs/frameworks as specified by the user from the linker
line into the final linked image.
This way, we can explicitly signal if a test requires the presence
of macOS SDK to build. For instance, when testing our in-house
MachO linker for correctly linking Objective-C, we require the
presence of the SDK on the host system, and we can enforce this
with `-Denable-macos-sdk` flag to `zig build test-standalone`.
* Don't skip the TLS initialization (Fixes#9083)
* Add a test case where a PIE program is built and run
* Refactor the common initialization code in the Linux startup
sequence.
Clang has a completely inconsistent CLI for its integrated assembler for
each target architecture. For x86_64, for example, it does not accept
an -mcpu parameter, and emits "warning: unused parameter". However, for
ARM, -mcpu is needed in order to properly lower assembly to machine code
instructions (see new standalone test case provided thanks to @g-w1).
This is a compromise between
b8f85a805b and
afb9f695b1.
This commits permits passing in static archives using the system
lib flag `-la`. With this commit, `zig ld` will now look firstly for
a dynamic library (which always takes precedence), and will fall back
on `liba.a` if the dylib is not found. The static archive is searched
for in the system lib search dirs like the dylibs.
Tests a scenario where the linker line has the following:
```
main.o libA.a libB.a
```
where `main.o` pulls a symbol from `libB.a`, which in turn is
dependent on a symbol from `libA.a`.
The steps to repro this issue are:
zig build-obj hello.zig -target x86_64-windows-msvc
zig build-exe hello.obj -target x86_64-windows-msvc --subsystem console
-lkernel32 -lntdll
What was happening is that the main Compilation added a work item to
produce kernel32.lib. Then it added a sub-Compilation to build zig's
libc, which ended up calling a function with extern "kernel32", which
caused the sub-Compilation to also try to produce kernel32.lib. The main
Compilation and sub-Compilation do not coordinate about the set of
import libraries that they will be trying to build, so this caused a
deadlock.
This commit solves the problem by disabling the extern "foo" feature
from working when building compiler_rt or libc. Zig's linker code is now
responsible for putting the appropriate import libs on the linker line,
if any for compiler_rt and libc.
Related: #5825
This commit makes it possible to obtain pointers to `extern` variables
at comptime.
- `ir_get_var_ptr` employs several checks to determine if the given
variable is eligible for obtaining its pointer at comptime. This
commit alters these checks to consider `extern` variables, which have
runtime values, as eligible.
- After this change, it's now possible for `render_const_val` to be
called for `extern` variables. This commit modifies
`render_const_val` to suppress the value generation for `extern`
variables.
- `do_code_gen` now creates `ZigValue::llvm_global` of `extern`
variables before iterating through module-level variables so that
other module-level variables can refer to them.
This solution is incomplete since there are several cases still
failing:
- `global_var.array[n..m]`
- `&global_var.array[i]`
- `&global_var.inner_struct.value`
- `&global_array[i]`
Closes#5349
