commit 9d1816111d1d30e18b8cb43a4aa31c194fb204c4 used the "output path"
as the path for passing shared library artifact paths to the Zig CLI.
For Windows, this was incorrect because it would pass the .dll instead
of the .lib file. This commit passes the "output lib path" instead,
which makes it pass the .lib path in case of a .dll on Windows.
This way the linker does not complain and say, "bad file type. Did you
specify a DLL instead of an import library?"
See #5854
Some tiny tweaks too:
* Use `wasm-freestanding-musl` instead of `wasm32-freestanding-musl`,
making it pointer-size-agnostic.
* Fix trying to build non-existent wasm musl start files.
Positional shared library arguments were not being detected as causing
dynamic linking, resulting in invalid linker lines. LLD did not have an
error message for this when targeting x86_64-linux but it did emit an
error message when targeting aarch64-linux, which is how I noticed the
problem.
This surfaced an error having to do with fifo.pipe() in the cat example
which I did not diagnose but solved the issue by doing the revamp that
was already overdue for that example.
It appears that the zig-window project was exploiting the previous
behavior for it to function properly, so this prompts the question, is
there some kind of static/dynamic executable hybrid that the compiler
should recognize? Unclear - but we can discuss that in #7240.
* it is now -fcompiler-rt and -fno-compiler-rt to override the (quite
reasonable) default of bundling compiler-rt only for executables and
dynamic libraries.
- the build.zig API is still called bundle_compiler_rt however it is
now an optional bool instead of a bool. leaving it as `null` means
to use the compiler default.
* renamed some internal identifiers to make the source more readable
* additionally support -fcompiler-rt when doing build-obj for ELF files
since that target already supports linking multiple objects into one.
- includes an error message when attempting this for non-ELF. in the
future this could additionally be supported with a more advanced
implementation that does not rely on the linker.
* properly populate the linker cache hash
I spent a long time working on this data structure, and I still think
it's a neat idea, but it has no business being in the std lib.
I'm aware of the few remaining references to SegmentedList that exist in
the std lib, but they are dead code, and so I'm leaving the dead
references as a clue that the code is dead. Cleaning up dead code will
be a separate effort that involves code coverage tools to make sure we
find it all.
std-lib-orphanage commit: 2c36a7894c689ecbaf63d5f489bb0c68773410c4
closes#7190
* Switch to using unicode when parsing the command line on windows
* Apply changes by LemonBoy and *hopefully* fix tests on MIPs
Co-authored-by: LemonBoy <LemonBoy@users.noreply.github.com>
* Fix up next and skip
* Move comment to more relevant place
Co-authored-by: LemonBoy <LemonBoy@users.noreply.github.com>
ZigTypeIdOptional types have a different way of specifying their payload
value depending on whether the child type is a pointer or not (plus some
other special cases).
Fixes#7251
stderr_mutex may still be held when we reach the signal handler, grab
our own stderr handle to print the error messages and avoid deadlocking.
Closes#7247
Before this commit, the branch regressed this case:
zig build-lib foo.zig -dynamic
readelf -d libfoo.so
x000000000000000e (SONAME) Library soname: [libfoo.so]
Now it works again, but it preserves the property that using `zig cc`
has the SONAME off by default to match C compilers.
