I am sorry I wasn't clear, I didn't mean there was a difference. I was just
wondering if...

Thanks for your answer :)

Cheers!

On Mon, Aug 12, 2019 at 9:03 PM 'Thomas Lively' via emscripten-discuss <
[email protected]> wrote:

> -pthread and -s USE_PTHREADS should be identical. If they are not that is
> a bug we should look into. If you could file an issue on the Emscripten
> repository with details that would be great.
>
> Either flag should work fine for compiling dependencies.
>
> On Aug 12, 2019, at 09:05, Mehdi Sabwat <[email protected]> wrote:
>
> Hi Thomas,
>
> Thank you for your answer it seems the difference between -s
> USE_PTHREADS=1 and -pthread lies within the JS code generation. But I am
> not sure.
>
> My case is I am cross compiling a library that I will use as a module for
> a main.c, the main file will be compiled and linked with -s USE_PTHREADS=1
> and other options (WEBGL, PTHREAD_PROXY etc...), do I need to compile all
> the dependencies with -s USE_PTHREADS=1 or is -pthread enough?
>
> Thanks !
> Regards
>
> On Wednesday, July 24, 2019 at 11:55:07 PM UTC+2, Thomas Lively wrote:
>>
>> Hi Dylan,
>>
>> Here's what these errors mean in more detail.
>>
>> wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory
>> must be used
>>
>> This one means that `dl_lib.o` was compiled with -pthread already
>> (-pthread enables the 'atomics' feature), so its atomic operations have
>> been lowered to real atomic WebAssembly instructions. However, because
>> you're not passing -pthread at link time, the linker tries to produce a
>> module with an unshared memory, which would make those atomic instructions
>> invalid.
>>
>> wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed
>> by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.
>>
>> This line tells us that ConcurrentScheduler.cpp.o was compiled without
>> -pthread, which means its atomic operations were lowered to non-atomic
>> WebAssembly instruction because the atomics feature was not enabled. That
>> means that ConcurrentScheduler.cpp.o is not safe to link with dl_lib.o
>> because the resulting program would not be thread-safe, even if the program
>> was thread-safe at the source level. When using the LLVM backend, the
>> wasm-ld linker helpfully recognizes this error and does not let you link an
>> unsafe program. Fastcomp would just silently link your program into a
>> thread-unsafe binary.
>>
>> As Mehdi said, you can either make sure to use -pthread when building all
>> your objects and libraries and at link time to get a properly thread-safe
>> binary out, or alternatively you can make sure not to pass -pthread for any
>> of the objects and libraries to get a single-threaded version of the binary
>> that will run on any engine.
>>
>> Let me know if I you want more detail on anything :)
>>
>> On Wed, Jul 24, 2019 at 2:41 PM Dylan Staley <[email protected]> wrote:
>>
>>> By adding the pthreads flag, will that change the behavior of the
>>> generated WASM module? I know that browsers like Chrome have experimental
>>> support for webassembly threads, but I'm aiming for a WASM module that
>>> works in older versions of Chrome as well.
>>>
>>> On Wed, Jul 24, 2019, 2:34 PM Mehdi Sabwat <[email protected]> wrote:
>>>
>>>> I think it's there, https://reviews.llvm.org/D59625 . The backend
>>>> seems to disallow linking with objects that use atomics features and are
>>>> not tagged as such. That's how I have understood it. I fixed it in my
>>>> build by adding pthread to my CFLAGS.
>>>> You don't seem to have CFLAGS so prepending cmake with
>>>> CFLAGS="-pthread" should do the trick.
>>>> Let us know if it works :)
>>>>
>>>> On Wednesday, July 24, 2019 at 11:04:29 PM UTC+2, Dylan Staley wrote:
>>>>>
>>>>> Hello! I recently heard about the new WebAssembly backend, and wanted
>>>>> to give it a try to compare against the fastcomp backend. I've 
>>>>> successfully
>>>>> compiled this project using `latest`, but when I switch to
>>>>> `latest-upstream` I get the following issue during linking:
>>>>>
>>>>> ```
>>>>> wasm-ld: error: 'atomics' feature is used by d1_lib.o, so
>>>>> --shared-memory must be used
>>>>> wasm-ld: error: Target feature 'atomics' used in d1_lib.o is
>>>>> disallowed by ConcurrentScheduler.cpp.o. Use --no-check-features to
>>>>> suppress.
>>>>> ```
>>>>>
>>>>> The actual command that failed was:
>>>>> ```
>>>>> shared:ERROR: '/home/staley_dylan/emsdk/upstream/bin/wasm-ld -o
>>>>> /tmp/emscripten_temp_DthpaW/td_wasm.wasm --allow-undefined --import-memory
>>>>> --import-table --lto-O0
>>>>> CMakeFiles/td_wasm.dir/td/telegram/td_emscripten.cpp.o libtdjson_static.a
>>>>> tdactor/libtdactor.a libtdjson_private.a libtdclient.a libtdcore.a
>>>>> tdnet/libtdnet.a ../crypto/lib/libssl.a tddb/libtddb.a 
>>>>> tdactor/libtdactor.a
>>>>> tdutils/libtdutils.a sqlite/libtdsqlite.a ../crypto/lib/libcrypto.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libz.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc-wasm.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc++-noexcept.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc++abi.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc-extras.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libdlmalloc.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libpthreads_stub.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a
>>>>> /home/staley_dylan/.emscripten_cache/wasm-obj/libc_rt_wasm.a -mllvm
>>>>> -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj 
>>>>> -mllvm
>>>>> -disable-lsr --export __wasm_call_ctors --export __data_end --export main
>>>>> --export malloc --export free --export setThrew --export __errno_location
>>>>> --export htonl --export htons --export ntohs --export
>>>>> emscripten_builtin_memalign --export memalign --export _get_environ
>>>>> --export strlen --export _get_tzname --export _get_daylight --export
>>>>> _get_timezone --export emscripten_builtin_free -z stack-size=5242880
>>>>> --initial-memory=16777216 --no-entry --global-base=1024' failed (1)
>>>>> ```
>>>>>
>>>>> I assume this is something to do with shared memory support in WASM,
>>>>> but I haven't changed the configuration between a successful compile on
>>>>> `latest` and this failing one on `latest-upstream`. Does anyone have any
>>>>> idea? For reference, I'm trying to compile TdLib (
>>>>> https://github.com/tdlib/td
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftdlib%2Ftd&sa=D&sntz=1&usg=AFQjCNGFEkTIBqppIVw0j_ZPWBcfUNRVsw>
>>>>> ).
>>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "emscripten-discuss" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/emscripten-discuss/tdjKEcKXXC8/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/emscripten-discuss/977d6ddf-d05b-40c5-a27d-37094d096252%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/977d6ddf-d05b-40c5-a27d-37094d096252%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/CA%2Bu72ZnbstT4XzQs7uMszj5%2BX%2BCoAsZy4ggiBu0ujOt9UwvOuQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CA%2Bu72ZnbstT4XzQs7uMszj5%2BX%2BCoAsZy4ggiBu0ujOt9UwvOuQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/d246edfc-c639-4e14-a544-e3b5406ffebc%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/d246edfc-c639-4e14-a544-e3b5406ffebc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CC638F3B-AC30-4033-9D04-537941D2A418%40google.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CC638F3B-AC30-4033-9D04-537941D2A418%40google.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CANLCay%3DWZe0mDztnwGbP1RrVCNv2TUHN0p55YGrNiFMLBqx%3DbA%40mail.gmail.com.

Reply via email to