Andrey Khonich

Results 64 comments of Andrey Khonich

Ok, i finally was able to compile almost everything by using msys2 instead of mingw64.

Rolled back to 3.1.45 - throws the same error: attempt to add bitcode file after LTO. P.S. Once again have to use 3.1.41

Any updates regarding the issue? Tried again 3.1.46 and it still reports the same error: wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libc-mt.a(proxying_legacy.o): attempt to add bitcode file after LTO. 3.1.41 is linking fine, all...

Btw build.ninja has this linker command: ############################################# # Link the executable Release\bin\tmrwRooms.js build Release/bin/tmrwRooms.js: CXX_EXECUTABLE_LINKER__tmrwRooms_Release TmrwApplications/src/roomsExplorer/CMakeFiles/tmrwRooms.dir/Platform/Wasm/wasmApp.cpp.o ... ... FLAGS = -flto -frtti -O3 -DNDEBUG -s USE_SDL=2 --bind -s ALLOW_BLOCKING_ON_MAIN_THREAD=1 -pthread...

i updated emsk with ./emsdk install tot. It reports the same error, but in another file now... wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libhtml5.a(callback.o): attempt to add bitcode file after LTO (_emscripten_run_callback_on_thread)

Any updates regarding the issue? For me still last working version remain 3.1.41. All further emsdk versions failing with different errors. Latest emsdk 3.1.47 throws error: wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libhtml5.a(callback.o): attempt...

Just got 3.1.51 emsdk, The issue is still there. The same linking error for the builds with lto + pthreads.

I'm not exactly sure when this start happening, because normally i do not check workers in profiler. I think 3 month ago workers looked good in profiler, in idle state...

The earliest emsdk i could rollback is 3.1.52. And the issue with busy workers still exists there. When i tried to rollbcak to 3.1.50 - engine crashed. Looks like emscripten...

I'm not using wait in main thread. Please check the screenshots above. I'm talking about nearly 100% cpu usage in pthread function loop (ie Worker) where i use function: std::condition_variable.wait(std::unique_lock...