to be installed when linking libc.
When zig links against libc, it requires a dynamic linker path.
Usually this can be determined based on the architecture and operating
system components of the target. However on some systems this is not
correct; because of this zig checks its own dynamic linker.
When zig is statically linked, this information is not available, and so
it resorts to using cc -print-filename=foo to find the dynamic linker
path.
Before this commit, Zig incorrectly exited with an error if there was
no c compiler installed. Now, Zig falls back to the dynamic linker
determined based on the arch and os when no C compiler can be found.
* 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.
* fix crash when doing field access of slice types. closes#2486
* remove the deprecated Child property from slice types
* add -Dskip-non-native build option to build script
Stuffing all the files together and compiling the resulting blob with
the main program is a terrible idea.
Some files, namely the .S ones, must be run trough the C preprocessor
before assembling them (#2437).
Beside that the aggregate may be mis-compiled due to the presence of
some flags that affect the following code.
For example let's consider two files, a.s and b.s
a.s
```
fn1:
ret
.data
data1:
.word 0
```
b.s
```
fn2:
ret
```
Now, fn1 and fn2 will be both placed in the .text section as intended if
the two files are compiled separately. But if we merge them the `.data`
flag ends up placing fn2 in the wrong section!
This fixes a nasty crash where musl's memset ended up in the
non-executable data segment, leading to too many hours of
head-scratching.
The `arena` instance being used bythe parse tree was valid and
pointed to valid memory, but existed as a local variable inside the
stack frame of the `parse` function (the `const arena`), which was never
stored anywhere before leaving the scope.
This meant that code above the `parse` function saw a valid instance of
an `ArenaAllocator` that pointed to the same backing memory, but didn't
posess any of the local state built up after the call to `parseRoot`,
basically the caller saw an empty arena.
This meant that when `deinit` was called, it saw an Arena with 0
allocations in it's `buffer_list` and wasn't able to destroy any of the
memory. This caused it to leak and caused FailingAllocator to balk.
The fix is to make sure the parse tree is using the same instance of
ArenaAllocator as is reported up the call stack, the one inside the
`Tree{}` object. I'm not sure why that field is marked with a comment
to remove it, as it's used by the `std.ast.Tree.deinit()` function, but
this change seems to solve the problem.
stage1 translate-c actually has this wrong. When exporting a function,
it's ok to use empty parameters. But for prototypes, "no prototype"
means that it has to be emitted as a function that accepts anything,
e.g. extern fn foo(...) void;
See #1964