ABI changes in 1.38.47

[Alon Zakai]

Hello everyone,

In the just-tagged release 1.38.46 there are changes to our internal ABI,
specifically, the errno constants have changed.

This should not be noticeable in portable code, that is, if you use the
errno C constants (EBADF, EINVAL, etc.) then everything should be fine.
However, if you assume the actual integer value of those, or mix code built
with the old ABI with the new compiler, you can get errors.

To be safe, you should always rebuild from source all code and libraries in
every emscripten release, as we do not guarantee that the internal ABI is
stable (intentionally, so that we can improve it over time, as we are doing
now).

Background: The new errno constants match the ones in wasi, see
https://github.com/emscripten-core/emscripten/pull/9545 This is part of a
refactoring of our syscalls that will both decrease code size (by avoiding
annoyances in musl's syscalls like being variadic) and also allow emcc
output to run in wasm runtimes like wasmer and wasmtime. Note that this
process will take more than one release (we are doing one syscall at a
time, gradually), so the ABI will keep changing for a while.

Please test and report any unexpected breakage!

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQentE24B2rJENfAXQMB3g97rU%2BBQ8HDixmO6i5nuCuMQ%40mail.gmail.com.

Re: Patching Emscripten: preserving good practices

[Alon Zakai]

Yeah, given this has happened more than once, I tend to agree that it may
be worth us having ffmpeg tests in upstream. We'd need to measure how long
the build takes, but if it's reasonable, I'd support it.

On Wed, Oct 2, 2019 at 12:35 PM Beuc  wrote:

> I just upgraded 1.38.45->1.38.46 and I got a new build failure in an
> unmodified ffmpeg build.
> Which is also what happened last time I upgraded Emscripten 1 month ago
> (different error).
> I don't see wasm-ld-related notes in the ChangeLog, but apparently it got
> stricter again.
> Compiling a few external libs may actually be a good release test case for
> the Emscripten project ¯\_(ツ)_/¯
>
> - Beuc
> On 20/09/2019 20:06, Beuc wrote:
>
> Hi,
> On 17/09/2019 00:18, Alon Zakai wrote:
>
> On Mon, Sep 16, 2019 at 6:50 AM Beuc  wrote:
>
>> > * Are there tests in your codebase that we could run in upstream
>> emscripten?
>>
>> Come to think of it, there's one thorough automated test that we have to
>> run at each upgrade:
>> building dependencies!
>> [...]
>>
> It might be useful to set up CI that runs the emscripten tip-of-tree
> builds on that (emsdk install tot-fastcomp or tot-upstream). Those are
> literally the very newest code, that passed chromium CI but is not as
> heavily tested as the actual release tags. You may sometimes see a
> temporary breakage you can ignore, but it would also catch regressions.
>
> There seem to be a misunderstanding, you asked for test you could run, not
> the other way around ;)
>
> It isn't worth it for us to constantly rebuild with ToT: most of the time
> we're working on Ren'Py/RenPyWeb itself and can't afford varying
> dependencies.
> Investigating all temporary and non-temporary breakages sounds like time I
> should reserve for properly upgrading and adapting to a newer, stable
> Emscripten once every other month.
>
> - Tagging: TBH I didn't figure out yet e.g. "what LLVM commit is used for
> emsdk 1.38.42" from https://chromium.googlesource.com/emscripten-releases/
>
>
> Is that still an issue? Are the docs at
>
>
> https://github.com/emscripten-core/emscripten/blob/incoming/docs/process.md#packaging-emscripten
>
> (I hadn't seen this question on first read.)
>
> My first attempts with binaryen seems to work, and for those interested
> Sam Clegg posted a recap:
>
>
> https://github.com/emscripten-core/emscripten/issues/8995#issuecomment-532984238
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/3f1f8c14-8d50-d66d-f6fb-31c588f42acf%40beuc.net
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS1%3DJEaQA%3DVXBZOYAbRjKwtq6u9aTUwE0nVTF_L__1H5Q%40mail.gmail.com.

Re: Patching Emscripten: preserving good practices

[Mehdi Sabwat]

Hi,

I am interested by this, will you please share the logs?

It might be irrelevant but, did you clear your cache before, rebuilding?

emcc --clear-cache

On Wed, Oct 2, 2019, 21:35 Beuc  wrote:

> I just upgraded 1.38.45->1.38.46 and I got a new build failure in an
> unmodified ffmpeg build.
> Which is also what happened last time I upgraded Emscripten 1 month ago
> (different error).
> I don't see wasm-ld-related notes in the ChangeLog, but apparently it got
> stricter again.
> Compiling a few external libs may actually be a good release test case for
> the Emscripten project ¯\_(ツ)_/¯
>
> - Beuc
> On 20/09/2019 20:06, Beuc wrote:
>
> Hi,
> On 17/09/2019 00:18, Alon Zakai wrote:
>
> On Mon, Sep 16, 2019 at 6:50 AM Beuc  wrote:
>
>> > * Are there tests in your codebase that we could run in upstream
>> emscripten?
>>
>> Come to think of it, there's one thorough automated test that we have to
>> run at each upgrade:
>> building dependencies!
>> [...]
>>
> It might be useful to set up CI that runs the emscripten tip-of-tree
> builds on that (emsdk install tot-fastcomp or tot-upstream). Those are
> literally the very newest code, that passed chromium CI but is not as
> heavily tested as the actual release tags. You may sometimes see a
> temporary breakage you can ignore, but it would also catch regressions.
>
> There seem to be a misunderstanding, you asked for test you could run, not
> the other way around ;)
>
> It isn't worth it for us to constantly rebuild with ToT: most of the time
> we're working on Ren'Py/RenPyWeb itself and can't afford varying
> dependencies.
> Investigating all temporary and non-temporary breakages sounds like time I
> should reserve for properly upgrading and adapting to a newer, stable
> Emscripten once every other month.
>
> - Tagging: TBH I didn't figure out yet e.g. "what LLVM commit is used for
> emsdk 1.38.42" from https://chromium.googlesource.com/emscripten-releases/
>
>
> Is that still an issue? Are the docs at
>
>
> https://github.com/emscripten-core/emscripten/blob/incoming/docs/process.md#packaging-emscripten
>
> (I hadn't seen this question on first read.)
>
> My first attempts with binaryen seems to work, and for those interested
> Sam Clegg posted a recap:
>
>
> https://github.com/emscripten-core/emscripten/issues/8995#issuecomment-532984238
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/3f1f8c14-8d50-d66d-f6fb-31c588f42acf%40beuc.net
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CANLCaymuSPabZcWnfNzKEyfVkLppenMg4VShVGDqPpSsvdAK%2Bw%40mail.gmail.com.

Re: Patching Emscripten: preserving good practices

[Beuc]

I just upgraded 1.38.45->1.38.46 and I got a new build failure in an
unmodified ffmpeg build.
Which is also what happened last time I upgraded Emscripten 1 month ago
(different error).
I don't see wasm-ld-related notes in the ChangeLog, but apparently it
got stricter again.
Compiling a few external libs may actually be a good release test case
for the Emscripten project ¯\_(ツ)_/¯

- Beuc

On 20/09/2019 20:06, Beuc wrote:
>
> Hi,
>
> On 17/09/2019 00:18, Alon Zakai wrote:
>> On Mon, Sep 16, 2019 at 6:50 AM Beuc > > wrote:
>>
>> > * Are there tests in your codebase that we could run in
>> upstream emscripten?
>>
>> Come to think of it, there's one thorough automated test that we
>> have to run at each upgrade:
>> building dependencies!
>> [...]
>>
>> It might be useful to set up CI that runs the emscripten tip-of-tree
>> builds on that (emsdk install tot-fastcomp or tot-upstream). Those
>> are literally the very newest code, that passed chromium CI but is
>> not as heavily tested as the actual release tags. You may sometimes
>> see a temporary breakage you can ignore, but it would also catch
>> regressions.
>>
> There seem to be a misunderstanding, you asked for test you could run,
> not the other way around ;)
>
> It isn't worth it for us to constantly rebuild with ToT: most of the
> time we're working on Ren'Py/RenPyWeb itself and can't afford varying
> dependencies.
> Investigating all temporary and non-temporary breakages sounds like
> time I should reserve for properly upgrading and adapting to a newer,
> stable Emscripten once every other month.
>
>>> - Tagging: TBH I didn't figure out yet e.g. "what LLVM commit is
>>> used for emsdk 1.38.42" from
>>> https://chromium.googlesource.com/emscripten-releases/
>>>
>>
>> Is that still an issue? Are the docs at
>>
>> https://github.com/emscripten-core/emscripten/blob/incoming/docs/process.md#packaging-emscripten
>
> (I hadn't seen this question on first read.)
>
> My first attempts with binaryen seems to work, and for those
> interested Sam Clegg posted a recap:
>
> https://github.com/emscripten-core/emscripten/issues/8995#issuecomment-532984238
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/3f1f8c14-8d50-d66d-f6fb-31c588f42acf%40beuc.net.

Is my application single- or multi-threaded?

[Simon Sandström]

Hello,

I have an application that first creates and setups a WebSocket, like
this:

  ws = emscripten::val::global("WebSocket").new_(emscripten::val(...));
  ws.set("onopen", emscripten::val::module_property("onopen"));
  ws.set("onmessage", emscripten::val::module_property("onmessage"));

and then it sets a main loop with emscripten_set_main_loop(...).
Everything works fine right now as there are no shared resouces between
onopen/onmessage and the code that is run in the main loop, but in the
future it will be.

Is my application multi-threaded? Can the onopen/onmessage event fire
and execute at the same time as my main loop? Answers online are mostly
old and says that there are no multi-threading in browser JavaScript,
but what about web workers? Are they involved in this scenario?


- Simon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/20191002122818.7pjxllqnqrc3nayz%40simon-laptop.