Emscripten IDBFS issue with raylib-zig and zig 0.16

Help
,
2

I could not reproduce the issue, IDBFS works on both 0.15 and 0.16. I however needed to make the following addition/changes to your repro:

  • Create the directory resources and an empty file inside of it.
  • For 0.16:
    • Run zig fetch --save git+https://github.com/raylib-zig/raylib-zig#97be2c7ae646a2f09856604b138c427c0af1b952 (the currently latest commit on the devel branch)
    • Remove the switch prongs that call takeown on Windows from all zemscripten build.zigs inside zig-pkg because they didn’t work on my system for some reason.
    • Add
      const std = @import("std");
pub const std_options_debug_io = std.Io.failing;
pub const panic = std.debug.no_panic;
      to main.zig.

I would suggest that you double-check that your browser hasn’t cached some earlier work-in-progress build of your repro. Other things that could cause issues:

  • By default, Emscripten may omit including the filesystem component if it detects that you aren’t using filesystem APIs (implementation details). raylib’s SaveFileData opens a file for writing so this should be the case for your repro, but you might want to be aware of this behavior if you’ve tested with e.g. an empty main function. You can pass -sFORCE_FILESYSTEM to emcc to disable this behavior.
  • If you’re passing --closure 1 to emcc to minify JavaScript and eliminate dead code, you want to make sure that symbols that are only referenced from your HTML shell or --pre-js/--post-js aren’t eliminated. For example, you might need to use Module['preRun'] = () => { FS['mount'](IDBFS, ...) }, as using indexers instead of dot access is the way you instruct Closure that a property must not be trimmed.

If the problem persists it’s almost certainly with how raylib/raylib-zig/emsdk/zemscripten are implemented, not Zig itself, so you will probably have better luck if you ask them for help directly.

As an aside, I personally really dislike how packages like raylib use emsdk (see my replies to this thread) and would advice against doing what they do. Building for Emscripten is very fickle and it’s easy to have the Emscripten cache end up in an inconsistent state, leading to confusing issues and inconsistencies that will be difficult for most users to untangle unless they are deeply familiar with Emscripten internals. It’s also a problem that things like emccStep hide important details about how the Emscripten toolchain is invoked and make it more difficult than necessary for users to customize or debug their emcc invocations when problems arise. Running emcc manually requires a few more lines of boilerplate code upfront, but is so much easier for a reader (= you in 3 months) to understand and debug.

3 Likes