-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). >>>> >>>> -- >>>> 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. >>> >>> -- >>> 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. > > -- > 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. -- 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.
