Thanks for testing!

Yeah, would be good to see if that corruption bug is something we need to
fix (not aware of any general compiler bugs like that currently). Would be
interesting to know if it happens in unoptimized builds too.

On Sat, Feb 23, 2019 at 7:27 PM Brion Vibber <[email protected]> wrote:

> Awesome, I'll hold off on the pthreads builds for now and see if I can
> work out the corruption issue in dav1d (either something's miscompiling, or
> something's just different between the asm.js and wasm builds in a legit
> way that I should be able to adjust).
>
> And thanks for all the good work!
>
> -- brion
>
> On Sat, Feb 23, 2019 at 7:25 PM Alon Zakai <[email protected]> wrote:
>
>> Likely __register_pthread_ptr needs to be exported in the wasm backend
>> path somewhere.  That may already be fixed on my wip branch,
>>
>> https://github.com/emscripten-core/emscripten/commits/wb-pthreads2
>>
>> but that hasn't landed yet (also some LLVM issues yet to be done - as
>> mentioned earlier, wasm backend + pthreads is not quite ready yet).
>>
>> On Sat, Feb 23, 2019 at 6:56 PM Brion Vibber <[email protected]> wrote:
>>
>>> Spoke too soon; modularized pthreads output builds but still doesn't run
>>> on upstream-3441, dying on thread setup:
>>>
>>> TypeError: Module.__register_pthread_ptr is not a function
>>>     at onmessage
>>>
>>> Is this likely to be a snapshotting sync issue with the latest vs
>>> latest-upstream builds, or does it need separate support for the llvm
>>> backend?
>>>
>>> -- brion
>>>
>>> On Sat, Feb 23, 2019 at 6:36 PM Brion Vibber <[email protected]> wrote:
>>>
>>>> On Fri, Feb 22, 2019 at 10:29 PM Brion Vibber <[email protected]> wrote:
>>>>
>>>>> libvpx (VP8/VP9 decoder) has some sort of linking failure partway
>>>>> through making libvpx.a so I can't build the modules. I'll try to narrow 
>>>>> it
>>>>> down.
>>>>>
>>>>
>>>> For single-threaded builds I found I'm having a problem with the .a
>>>> library being modified in some way that breaks it by the Linux "strip"
>>>> command. I've put a copy of the working/broken libraries and a small
>>>> program that shows up the problem at
>>>> https://github.com/brion/emscripten-library-strip-bug
>>>>
>>>> I can work around that by disabling the 'strip' command invocation (or
>>>> rather, replacing it with my own no-op command).
>>>>
>>>> Multithreaded libvpx builds have a more exciting failure in a test
>>>> case, which I'll document later, but the library itself seems to build ok
>>>> with today's updated latest-upstream-3441.
>>>>
>>>> Yay! Progress. :D
>>>>
>>>> -- brion
>>>>
>>> --
>>> 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 [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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 [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to