Not all of the softfloat library is being built....
Vector support is very buggy at the moment, but should work when the bugs are fixed.
(as I had the same code working with another vector function, that hasn't been merged yet).
* introduce wasm32-freestanding-musl .h files to fix
conflicts with stddef.h and errno.h
* fix an issue with zig build system regarding installation of
webassembly libraries
* add implementations to zig's libc:
- strcmp
- strncmp
- strerror
- strlen
See #514
- wip for #2046
- clang .d output must be created with `clang -MV` switch
- implemented in Zig
- hybridized for zig stage0 and stage1
- zig test src-self-hosted/dep_tokenizer.zig
* rename std/special/builtin.zig to std/special/c.zig
not to be confused with @import("builtin") which is entirely
different, this is zig's multi-target libc implementation.
* WebAssembly: build-exe is for executables which have a main().
build-lib is for building libraries of functions to use from,
for example, a web browser environment.
- for now pass --export-all for libraries when there are any
C objects because we have no way to detect the list of exports
when compiling C code.
- stop passing --no-entry for executables. if you want --no-entry
then use build-lib.
* make the "musl" ABI the default ABI for wasm32-freestanding.
* zig provides libc for wasm32-freestanding-musl.
Previously, `zig fmt` on the stage1 compiler (which is what we currently
ship) would perform what equates to `zig run std/special/fmt_runner.zig`
Now, `zig fmt` is implemented with the hybrid zig/C++ strategy outlined
by #1964.
This means Zig no longer has to ship some of the stage2 .zig files, and
there is no longer a delay when running `zig fmt` for the first time.
On macOS building with Xcode/clang the linker complains loudly when
symbol visibility is inconsistent. This option syncs visibilty setting
of both LLVM and Zig.
Previously libuserland was being built for the native target,
which could depend on native CPU features such as AVX. The
CI infrastructure is intending to create binaries that are
widely compatible and do not make use of specific CPU features.
There could be something to gain from enabling native CPU features
sometimes, by introducing a new cmake configuration option, but
since it's planned to eventually ship self-hosted rather than stage1,
I don't think it really matters.
closes#2348
This modifies the build process of Zig to put all of the source files
into libcompiler.a, except main.cpp and userland.cpp.
Next, the build process links main.cpp, userland.cpp, and libcompiler.a
into zig1. userland.cpp is a shim for functions that will later be
replaced with self-hosted implementations.
Next, the build process uses zig1 to build src-self-hosted/stage1.zig
into libuserland.a, which does not depend on any of the things that
are shimmed in userland.cpp, such as translate-c.
Finally, the build process re-links main.cpp and libcompiler.a, except
with libuserland.a instead of userland.cpp. Now the shims are replaced
with .zig code. This provides all of the Zig standard library to the
stage1 C++ compiler, and enables us to move certain things to userland,
such as translate-c.
As a proof of concept I have made the `zig zen` command use text defined
in userland. I added `zig translate-c-2` which is a work-in-progress
reimplementation of translate-c in userland, which currently calls
`std.debug.panic("unimplemented")` and you can see the stack trace makes
it all the way back into the C++ main() function (Thanks LemonBoy for
improving that!).
This could potentially let us move other things into userland, such as
hashing algorithms, the entire cache system, .d file parsing, pretty
much anything that libuserland.a itself doesn't need to depend on.
This can also let us have `zig fmt` in stage1 without the overhead
of child process execution, and without the initial compilation delay
before it gets cached.
See #1964
