No longer automatically append the `--export` flag for each exported
function unconditionally. This was essentially a hack to prevent
binary bloat caused by compiler-rt symbols being always included in
the final binary as they were exported and therefore not garbage-
collected. This is no longer needed as we now support the ability to
set the visibility of exports.
This essentially reverts 6d951aff7e32b1b0252d341e66517a9a9ee98a2d
In #1622, when targeting WebAsembly, the --allow-undefined flag
became unconditionally added to the linker.
This is not always desirable.
First, this is error prone. Code with references to unkown symbols
will link just fine, but then fail at run-time.
This behavior is inconsistent with all other targets.
For freestanding wasm applications, and applications that only use
WASI, undefined references are better reported at compile-time.
This behavior is also inconsistent with clang itself. Autoconf and
cmake scripts checking for function presence think that all tested
functions exist, but then resulting application cannot run.
For example, this is one of the reasons compilation of Ruby 3.2.0
to WASI fails with zig cc, while it works out of the box with clang.
But all applications checking for symbol existence before compilation
are affected.
This reverts the behavior to the one Zig had before #1622, and
introduces an `import_symbols` flag to ignore undefined symbols,
assuming that the webassembly runtime will define them.
We definitely want a shared lock on a cache hit. Without this, we get a
deadlock when Zig is asked to compile the same C source file multiple
times as part of the same compilation.
This is a partial revert of 8ccb9a6ad327a4d7fbc321b33d4aa66a27a1f5ee.
cc @kcbanner
- C compilation flows didn't hold an exclusive lock on the cache manifest file when writing to it in all cases
- On windows, explicitly unlock the file lock before closing it
There are still a few occurrences of "stage1" in the standard library
and self-hosted compiler source, however, these instances need a bit
more careful inspection to ensure no breakage.
* Update for the breaking changes to std.fs.path.resolve. This had a
happy side effect of deleting some error handling code which is no
longer needed.
* Introduce cache_exempt_flags field to CSourceFile. This is used only
for include directories when building libc++ and libc++abi which
depend only on the zig lib path.
* libc_include_dir_list is only added to the cache hash when it
contains directories which have been obtained from system probing. It
is exempt when the directories depend only on the zig lib path.
Before, cache manifest files would have absolute file paths. This is
problematic for two reasons:
* Absolute file paths are not portable. Some operating systems such as
WASI have trouble with them. The files themselves are less portable;
they cannot be migrated from one user's home directory to another's.
And finally they can break due to file paths exceeding maximum path
component size.
* They would prevent some advanced use cases of Zig, where the lib dir
has a different path in a different invocation but is ultimately the
same Zig version and lib directory as before.
This commit adds a new column that specifies the prefix directory for
each file. 0 is an escape hatch and has the previous behavior. The other
two prefixes introduced are zig lib directory, and the cache directory.
This means files in zig-cache manifests can reference files local to
these directories.
In practice, this means it is possible to use a different file path for
the zig lib directory in a subsequent run of zig and have it still take
advantage of the global cache, provided that the files inside remain
unchanged.
closes#13050
There was no check for linker errors after flushing,
which meant that if the link failed the build would
continue and try to copy the non-existant exe, and
also write the manifest as if it had succeeded.
Also adds parsing of lld output, which is surfaced at the
end of the compilation with the other errors instead
of via stderr
Previously the compiler would crash on branching on undefined values
if you tried using `zig test` with a freestanding target since there
was no start code referencing `builtin.test_functions`.
Closes#12554
This reverts commit 06310e3d4eb47fed88b175891cb5865bb050f020, reapplying
commit a430630002bf02162ccbf8d3eb10fd73e490cefd.
I deeply apologize to @moosichu and those affected by this bug. The
original fix was actually fine. When I reverted it, I misremembered
how the Cache API works. I thought the fix was going to introduce
nondeterminism into the hash, but I forgot that the order of files in
the manifest doesn't actually matter when checking for a cache hit.
Actually, it does matter a little bit. This fix has a subtle downside
which is that it does introduce the possibility of false negatives when
checking for cache hits of 2+ iterations ago. For example, if the code
goes from "foo", to "bar", and then back to "foo", it may look like a
cache miss when it should have been a hit because 2 iterations ago the
code was the same. However, this is an uncommon use case, and all it
does is cause a bit of wasted time and disk space. That said, my
suggestion from earlier still applies and would be a nice follow-up
enhancement to this fix:
The proper solution to this is to, in whole cache mode, append the hash
inputs to some data structure, and then after the compilation is
complete, do some kind of sorting on the hash inputs so that they will
be the same order every time, then apply them in sequence. No lock on
the Cache object is needed for this scheme.
closes#11063
Windows gives AccessDenied if you delete a directory which contains open
file handles. This could be triggered when using CacheMode.whole when
cross compiling macho test binaries.
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.
Before this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
After this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
This matches stage1 behavior:
```
$ zig test -fstage1 lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
All tests are still run if `zig test` is run directly on `lib/std/std.zig`:
```
$ zig test lib/std/std.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
`zig build test-std` is unaffected by this change.
Closes#12926
The changes from https://reviews.llvm.org/D119173 mean that __config no
longer defaults the libc++ ABI to 1, relying on external configuration.
This means Zig must provide the external configuration.
This fixes static libraries built with zig with -lc++ to have the
standard __1 namespace prefix, which had previously regressed in the
llvm15 branch.
When linking libc and compiling natively, Zig tries to integrate with
the system C compiler. However, this caused Zig to fail when no system C
compiler is installed, despite the fact that Zig is perfectly capable of
compiling & linking libc without one.
This commit makes Zig fall back to using its own ability to provide libc
in the case that no C compiler is installed. For glibc, it means
sometimes getting the warning "zig cannot build new glibc version abc,
providing instead xyz".
Ideally, Zig would do some more validation about the system libraries
being linked against, and report an error in case it could not provide
the exact correct libc version of the system libraries (or that the
system libraries themselves conflict with each other), however, I think
it is fair to call that a separate enhancement.
Before, Zig tried to use its own libc files (e.g. glibc) when there were
no system libs being linked. This prevented building against native
glibc on systems that have newer glibc than the ones Zig provides.
Closes#12797
This adds the following for passthrough to lld:
- `--print-gc-sections`
- `--print-icf-sections`
- `--print-map`
I am not adding these to the cache manifest, since it does not change
the produced artifacts.
Tested with an example from #11398: it successfully prints the resulting
map and the GC'd sections.
This is problematic because in practice it depends on whether the
compiler backend supports it too, as evidenced by the TODO comment about
LLVM not supporting some architectures that in fact do support tail
calls.
Instead this logic is organized strategically in src/target.zig, part of
the internal compiler source code, and the behavior tests in question
duplicate some logic for deciding whether to proceed with the test.
The proper place to expose this flag is in `@import("builtin")` - the
generated source file - so that third party compilers can advertise
whether they support tail calls.
