Ah thanks! I added a comment with a link to my toy project and how to
reproduce the problem:
https://github.com/ziglang/zig/issues/10836#issuecomment-1044283663
On Thursday, 17 February 2022 at 19:33:32 UTC+1 alon...@gmail.com wrote:
> There is now this Zig issue for emscripten discussion,
There is now this Zig issue for emscripten discussion, more details might
make sense to add there, if any,
https://github.com/ziglang/zig/issues/10836
On Tue, Feb 1, 2022 at 3:44 AM Floh wrote:
> > Btw, did you get a chance to file a Zig ticket as you said?
>
> Haven't done that yet!
>
> On
> Btw, did you get a chance to file a Zig ticket as you said?
Haven't done that yet!
On Monday, 31 January 2022 at 18:51:07 UTC+1 alon...@gmail.com wrote:
> Nice, good to see pacman working!
>
> Btw, did you get a chance to file a Zig ticket as you said?
>
>
> On Mon, Jan 31, 2022 at 1:53 AM
Nice, good to see pacman working!
Btw, did you get a chance to file a Zig ticket as you said?
On Mon, Jan 31, 2022 at 1:53 AM Floh wrote:
> PS: the missing __stack_chk_* symbol errors I mentioned formerly are
> unrelated to the target triple, but instead happen when compiling via Zig
> in
PS: the missing __stack_chk_* symbol errors I mentioned formerly are
unrelated to the target triple, but instead happen when compiling via Zig
in debug mode. In that case, Zig compiles the C code with clang's
"-fstack-protector-strong" which requires two externally defined symbols, a
Ok, here's the result:
https://floooh.github.io/pacman.zig/pacman.html
Build instructions:
https://github.com/floooh/pacman.zig#experimental-web-support
...and a quick explanation how it works, and what workarounds are currently
required (and below that is the actual build function):
I'm pretty sure EMSCRIPTEN_KEEPALIVE won't have the intended behaviour of
actually exporting symbols when compiled with non-emscripten triples.
On Sat, Jan 29, 2022 at 4:08 PM Floh wrote:
> Thanks for the thorough explanation Sam! Regarding this PR:
>
Thanks for the thorough explanation Sam! Regarding this
PR: https://github.com/emscripten-core/emscripten/pull/16149, as far as I
have seen, only the EM_JS() macros caused trouble (with a non-emscripten
triple), I haven't seen any linker warnings regarding EMSCRIPTEN_KEEPALIVE
functions (which
Short term fix/wrokaround is here:
https://github.com/emscripten-core/emscripten/pull/16149
On Sat, Jan 29, 2022 at 11:32 AM Sam Clegg wrote:
> The undefined symbol error you are seeing here is coming from the
> post-linking phase. The way EM_JS works is that the function is that
> function
The undefined symbol error you are seeing here is coming from the
post-linking phase. The way EM_JS works is that the function is that
function `foo` declared as external using
`__attribute__((import_name("foo")))` and the data symbol `__em_js_foo` is
defined in the data section along with
Spot on Alon :)
It works if I hardwire just the C library (with the EM_JS functions) to the
wasm32-emscripten triple.
The Zig code needs to be compiled either with wasm32-wasi or
wasm32-freestanding, when using wasm32-emscripten, parts of the Zig stdlib
won't compile.
Also, when I tried to
Sam can confirm, but I would guess perhaps the emscripten triple is
necessary. That is, clang and/or wasm-ld might do something for EM_JS code
but only in emscripten mode.
If we can confirm that then we should definitely get a bug filed on Zig -
hopefully it would be easy to add support for the
PS: the .js file generated by emcc has functions like this:
/** @type {function(...*):?} */
function _sapp_js_add_beforeunload_listener(
) {
err('missing function: sapp_js_add_beforeunload_listener'); abort(-1);
}
(...ok, so that's where the JS console error is coming from...)
On Saturday, 29
13 matches
Mail list logo
