Update to zig version 0.14.0-dev.2802+257054a14 #173
Conversation
rohlem
changed the title
|
This is awesome, I really appreciate it! |
rohlem
force-pushed
the
update-zig-to-0.14.0-dev.2628+5b5c60f43
branch
from
92d3993 to
71e4c81
Compare
|
I ran into this earlier (the #zig-help thread and one of the gh issues is actually mine). |
|
@rohlem I can't seem to build your branch on your fork: do you know why off the top of your head? Looks potentially related to forks you made of the dependencies. |
|
@MichaelBelousov that function signature was changed from 1 to 2 arguments in ziglang/zig@ba37a43 , so the easiest explanation would be if you're using a Zig version before that. |
|
that makes perfect sense, thank you for pointing that out, I did in fact just try using a an older 0.14.0 I had lying around and hoped it would work. Sorry I should have tried upgrading earlier. I'll take a look later again |
|
Okay, when initially building step To make these sub-compilations succeed, On the front of updating to current ziglang.org-downloadable master ( |
ziglang/zig#21220 and I saw somebody on discord work around it by doing an explicit |
Eh, that's also related to types, but a bit of a different scenario. The explicit cast in C would probably be the better workaround in the meantime. |
Ah I see - yes that makes sense. I don't meant to pressure you into sinking more time into it. I very much appreciate the effort you've already put in! |
# Conflicts: # src/Font.zig
…encies to newer versions / updated forks for now
rohlem
force-pushed
the
update-zig-to-0.14.0-dev.2628+5b5c60f43
branch
from
3f570a1 to
af56131
Compare
rohlem
changed the title
No worries! I was just wary of maybe a dozen more issues creeping up, but that constant was the only place that triggered a compile error. I rebased onto current
(EDIT: new version |
|
Thank you!! |
|
@rohlem I'm getting this when compiling against sdl2: /home/dvanderson/.cache/zig/p/12200aa79b05aaeefff144b9e376371e2e7ddc982b9207d146163baf56361331a834/src/stdlib/SDL_string.c:373:12: error: call to undeclared function 'wcslcpy'; ISO C99 and later do not support implicit function declarations I'm going to work around it for now, but does that ring any bells for you? |
|
Nope, haven't run into that. It reads like a missing |
|
Good question, I'm not sure. We are setting .link_libc = true in build.zig and I'm getting the error from:
I always assumed it was the system libc when I'm not cross compiling. This is on Linux Mint 21.3. |
I believe that's true. It might change as soon as you specify a |
|
Thanks very much for the info - you are totally right. Looks like my system is still on glibc 2.35. I agree - we'll keep them disabled for now. Thanks! |
|
am I still building this wrong @rohlem? $ cd dvui
$ git checkout e50cfbf7d3cba03552cd85a9b368a0940b1f9d9b # the merge commit from this PR
$ ~/opensource/zig-linux-x86_64-0.14.0-dev.2802+257054a14/zig
0.14.0-dev.2802+257054a14
$ ~/opensource/zig-linux-x86_64-0.14.0-dev.2802+257054a14/zig build web-testMy version looks correct according to the PR title, I see it changed once in the convo. I get: |
|
nevermind, I now see the comment referenced in the conversation about having to build .wasi first |
|
non-debug mode builds for me with the following patch which I could turn into a PR, diff --git a/build.zig b/build.zig
index 2559c8b..21ab254 100644
--- a/build.zig
+++ b/build.zig
@@ -51,7 +51,7 @@ pub fn build(b: *std.Build) !void {
};
const webtarget_exe = std.Target.Query{
.cpu_arch = .wasm32,
- .os_tag = .freestanding, //the initial build of this fails for me. => change to .wasi once, build fails, change back to .freestanding, build succeeds
+ .os_tag = .wasi, //the initial build of this fails for me. => change to .wasi once, build fails, change back to .freestanding, build succeeds
.abi = .musl,
};
diff --git a/examples/web-test.zig b/examples/web-test.zig
index cc3f67a..0b2ba9e 100644
--- a/examples/web-test.zig
+++ b/examples/web-test.zig
@@ -219,3 +219,7 @@ fn dvui_frame() !void {
win.content_scale = ns;
}
}
+
+export fn main(_: u32, _: u32) u32 {
+ return 0;
+}
diff --git a/src/backends/WebBackend.zig b/src/backends/WebBackend.zig
index 832f780..511c02d 100644
--- a/src/backends/WebBackend.zig
+++ b/src/backends/WebBackend.zig
@@ -57,8 +57,8 @@ pub const wasm = struct {
pub extern fn wasm_add_noto_font() void;
};
-export const __stack_chk_guard: c_ulong = 0xBAAAAAAD;
-export fn __stack_chk_fail() void {}
+//export const __stack_chk_guard: c_ulong = 0xBAAAAAAD;
+//export fn __stack_chk_fail() void {}
export fn dvui_c_alloc(size: usize) ?*anyopaque {
//std.log.debug("dvui_c_alloc {d}", .{size});Basically, in my zig-help thread I encountered a similar issue and noticed that dvui exports its own Also note that I had to add a fake main function for the wasm linker, I assume this zig version's compiler or build system's handling of So it builds now but (regardless of optimization setting) at runtime the webassembly fails to import with: I will look into that. |
|
I have an MVR, I will talk to zig folks, it doesn't like like wasm is in a good state on master |
|
After some testing, thinking and asking zig-help, it looks like the way we should do this is An alternative is to use something like |
Continuation of #119 .
Some dependencies also aren't upstream-updated yet, so I created updated forks and linked to them in
build.zig.zonfor now.With this, on Windows 11 I was able to build and run all examples (
sdl-(standalone|ontop),dx11-(standalone|ontop),raylib-(standalone|ontop),web-test).I also tried to get the
-Dsdl3flag working, and got it from compile errors to "unable to find artifact 'sdl3'".EDIT: However,
web-testcurrently requires a workaround that breaks for non-Debugoptimization modes. (See below.)Most of the changes should be straightforward, the main motivators being ziglang/zig#21225 and ziglang/zig#16865 / ziglang/zig#21817 .
The only unfortunate change/workaround is in
build.zig:ziglang/zig#22240 removed libc support for the target
wasm32-freestanding-musl.This means for
web-test, when compiling moduledvui_mod_webfor this target, libc headers aren't found:Fwict the primary motivation for this was that
freestandingmeans having no system interface, whilemuslas an ABI implies a particular system interface.However, the headers here are primarily math helper functions. Previously zig would provide these for this target, now it doesn't anymore.
The fix should be to instead specify a libc-available target, such as
wasm32-wasi-musl, however linking two objects for this target together currently results in a duplicate symbol error:I think this might well be an upstream zig issue (those two symbols should be weak or something).
I haven't found mention of this on the GitHub issue tracker (though there's similar issue ziglang/zig#22096 ),
however someone reported it in a
#zig-helpdiscord thread: https://discord.com/channels/605571803288698900/1302304150792568862The workaround for now seems to be to target
wasifor only one object, andfreestandingfor all others.An upstream report would probably be good, however I don't know much about wasm, so if someone else were able to reduce it to a minimal example, that would be great.
Also note that the target workaround actually only seems to work for Debug optimization mode.
With any other optimization mode, zig refuses to link because wasm-ld warns
wasm-ld: warning: Linking two modules of different target triples: '...\dvui\.zig-cache\o\6222e68294243b2dfd92cc297ecb1962\web-test.wasm.o' is 'wasm32-unknown-unknown-musl' whereas 'ld-temp.o' is 'wasm32-unknown-wasi0.1.0-musl'.So this really is just a brittle, temporary workaround.