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] > <javascript:>> 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] >> <javascript:>> 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] <javascript:>. >>> 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] <javascript:>. >> 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.
