In the CI system, I copied the old tarball and then applied
05c21a26cb2d5daf06191bd996d0770192704b66 to its compiler_rt
implementation.
After this is verified we can drop this commit and regenerate the
tarballs from a master branch commit.
Before it was checking if the compiler was AppleClang, however, this did
not handle the case when using a compiled-from-source Clang on a macOS
computer, in which case the linker is still Apple ld64, and it is in
fact the linker that needs to have the different flag to communicate
stack size.
This branch largely reverts 58f961f4cb9875bbce3070969438ecf08f392c9f. I
would like to revisit the proposal to modify the standard library in
this way and think more carefully about it before adding isAbsolute()
checks everywhere.
In ea9ad1e85dd5e2ba18e7d55f7a7f9694282159f1, I incorrectly applied
boolean logic to one of the pieces of logic, resulting in a regression
in translate-c.
This flag makes CI servers print garbage to the terminal. I started
implementing detection in wasi.c, but it would have destroyed the
beautiful code that only touches the C stdlib, does not do any
conditional compilation based on the operating system, or rely on any
POSIX functions.
So instead, let's just do without this flag to retain simplicity in this
step of the build process.
This takes a bit longer since the interpreted part has to do more work
but it saves a round trip through the compiler by allowing `zig2 build`
to be the final step. 1-2-3, done.
For me this is currently failing due to compilation errors generated by
GCC when compiling zig2.c but in theory if those are fixed, it should
work!
* synchronize zig1.c from zig-wasi external project
* change the way argv works to avoid absolute paths
* autodetect isatty
* compiler_rt: disable some functions when object format is C
* add missing flag from config.zig.in
The next problem is that compiling compiler_rt.c with gcc gives
"conflicting types" errors for `__eqhf2` and friends.
