rahulchaphalkar commented 5 years ago

I'm trying to compile the skia's Canvaskit to wasm using emscripten 1.38.38 and LLVM upstream backend. Initially, i faced several linker errors from wasm-ld, but which could be resolved for now by manually using llvm-ranlib to index the different .a archives. (Errors looked like wasm-ld: error: out/canvaskit_wasm_debug/libskottie.a: archive has no index; run ranlib to add one) However, now I'm facing an error

wasm-ld: warning: function signature mismatch: _ZN9SkFontMgr10RefDefaultEv
>>> defined as (i32) -> void in out/canvaskit_wasm_debug/libskottie.a(libskottie.TextLayer.o)
>>> defined as (i32) -> void in out/canvaskit_wasm_debug/libskia.a(libskia.SkFontMgr.o)
 "/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/wasm-emscripten-finalize" /tmp/emscripten_temp_HKAsH4/canvaskit.wasm -o /tmp/emscripten_temp_HKAsH4/canvaskit.wasm.o.wasm --detect-features -g --input-source-map=/tmp/emscripten_temp_HKAsH4/canvaskit.wasm.map --output-source-map=/tmp/emscripten_temp_HKAsH4/canvaskit.wasm.o.wasm.map --output-source-map-url=/node_modules/canvaskit/bin/canvaskit.wasm.map --global-base=1024 --initial-stack-pointer=5243904
Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf
shared:ERROR: '/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_HKAsH4/canvaskit.wasm -o /tmp/emscripten_temp_HKAsH4/canvaskit.wasm.o.wasm --detect-features -g --input-source-map=/tmp/emscripten_temp_HKAsH4/canvaskit.wasm.map --output-source-map=/tmp/emscripten_temp_HKAsH4/canvaskit.wasm.o.wasm.map --output-source-map-url=/node_modules/canvaskit/bin/canvaskit.wasm.map --global-base=1024 --initial-stack-pointer=5243904' failed (1)

With the fatal error coming from wasm-emscripten-finalize. I wondered if this is because of https://github.com/emscripten-core/emscripten/issues/8905 , as this hasn't been updated in latest-upstream, only in incoming branch. Any help would be appreciated.

sbc100 commented 5 years ago

Him, this does look like a bug in binaryen.

However, GOT.func stuff should only be seen if you are trying to build with MAIN_MODULE or SIDE_MODULE? (Or maybe if you build with -fPIC). Are you doing this?

rahulchaphalkar commented 5 years ago

I checked, it doesn't look like I'm using any of those options. My sample compilation command line can be seen below:

/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/em++ -v -Oz --closure 1 --llvm-lto 3 -DSK_RELEASE --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/release.js -DGR_GL_CHECK_ALLOC_WITH_GET_ERROR=0 -I. -Ithird_party/icu -Ithird_party/skcms -DSK_DISABLE_READBUFFER -DSK_DISABLE_AAA -lEGL -lGLESv2 -DSK_SUPPORT_GPU=1 -DSK_DISABLE_LEGACY_SHADERCONTEXT --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/cpu.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/gpu.js -std=c++14 --bind --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/preamble.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/helper.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/interface.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/skottie.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/preamble.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/util.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/color.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/font.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/canvas2dcontext.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/htmlcanvas.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/imagedata.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/lineargradient.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/path2d.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/pattern.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/radialgradient.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/htmlcanvas/postamble.js --pre-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/postamble.js --post-js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/ready.js /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/fonts/NotoMono-Regular.ttf.cpp /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/canvaskit_bindings.cpp /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/particles_bindings.cpp /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/skottie_bindings.cpp -DSK_INCLUDE_MANAGED_SKOTTIE=1 modules/skottie/utils/SkottieUtils.cpp out/canvaskit_wasm/libskottie.a out/canvaskit_wasm/libsksg.a out/canvaskit_wasm/libparticles.a out/canvaskit_wasm/libskshaper.a out/canvaskit_wasm/libharfbuzz.a out/canvaskit_wasm/libicu.a out/canvaskit_wasm/libskia.a -s ALLOW_MEMORY_GROWTH=1 -s EXPORT_NAME=CanvasKitInit -s FORCE_FILESYSTEM=0 -s MODULARIZE=1 -s NO_EXIT_RUNTIME=1 -s STRICT=1 -s TOTAL_MEMORY=128MB -s USE_FREETYPE=1 -s USE_LIBPNG=1 -s WARN_UNALIGNED=1 -s USE_WEBGL2=0 -s WASM=1 -o out/canvaskit_wasm/canvaskit.js
shared:INFO: (Emscripten: Running sanity checks)
clang version 9.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 667ca68bdef7673d84106c69a8ef0bd73c58f95e)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin
 "/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/clang-9" -cc1 -triple wasm32-unknown-emscripten -emit-obj -disable-free -main-file-name NotoMono-Regular.ttf.cpp -mrelocation-model static -mthread-model posix -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu generic -fvisibility hidden -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -coverage-notes-file /tmp/emscripten_temp_OdtPcF/NotoMono-Regular.ttf_0.gcno -resource-dir /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/lib/clang/9.0.0 -D __EMSCRIPTEN_major__=1 -D __EMSCRIPTEN_minor__=38 -D __EMSCRIPTEN_tiny__=38 -D _LIBCPP_ABI_VERSION=2 -D unix -D __unix -D __unix__ -D SK_RELEASE -D GR_GL_CHECK_ALLOC_WITH_GET_ERROR=0 -I . -I third_party/icu -I third_party/skcms -D SK_DISABLE_READBUFFER -D SK_DISABLE_AAA -D SK_SUPPORT_GPU=1 -D SK_DISABLE_LEGACY_SHADERCONTEXT -D SK_INCLUDE_MANAGED_SKOTTIE=1 -internal-isystem /include/wasm32-emscripten/c++/v1 -internal-isystem /include/c++/v1 -internal-isystem /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/lib/clang/9.0.0/include -internal-isystem /include/wasm32-emscripten -internal-isystem /include -Oz -Werror=implicit-function-declaration -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /home/rahulchaphalkar/wasm/skia/skia -ferror-limit 19 -fmessage-length 0 -fno-inline-functions -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -nostdsysteminc -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/libcxx -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/lib/libcxxabi/include -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/compat -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/libc -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/local/include -isystem/home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/zlib -isystem/home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/libpng -isystem/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/SDL -isystem/home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/freetype/include -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o /tmp/emscripten_temp_OdtPcF/NotoMono-Regular.ttf_0.o -x c++ /home/rahulchaphalkar/wasm/skia/skia/modules/canvaskit/fonts/NotoMono-Regular.ttf.cpp
clang -cc1 version 9.0.0 based upon LLVM 9.0.0svn default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include/wasm32-emscripten/c++/v1"
ignoring nonexistent directory "/include/c++/v1"
ignoring nonexistent directory "/include/wasm32-emscripten"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 third_party/icu
 third_party/skcms
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/libcxx
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/lib/libcxxabi/include
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/compat
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/libc
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/local/include
 /home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/zlib
 /home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/libpng
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/emscripten/system/include/SDL
 /home/rahulchaphalkar/.emscripten_cache/wasm-obj/ports-builds/freetype/include
 /home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/lib/clang/9.0.0/include
End of search list.
clang version 9.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 667ca68bdef7673d84106c69a8ef0bd73c58f95e)
.
.
.
.
.
cache:INFO: generating system library: libcompiler_rt.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libcompiler_rt.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc-wasm.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc-wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc++-noexcept.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc++-noexcept.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc++abi.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc++abi.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc-extras.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc-extras.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libgl.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libgl.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libdlmalloc.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libdlmalloc.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libpthreads_stub.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libpthreads_stub.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libcompiler_rt_wasm.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc_rt_wasm.a... (this will be cached in "/home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc_rt_wasm.a" for subsequent builds)
cache:INFO:  - ok
 "/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/wasm-ld" -o /tmp/emscripten_temp_OdtPcF/canvaskit.wasm --allow-undefined --import-memory --import-table --lto-O2 /tmp/emscripten_temp_OdtPcF/NotoMono-Regular.ttf_0.o /tmp/emscripten_temp_OdtPcF/canvaskit_bindings_1.o /tmp/emscripten_temp_OdtPcF/particles_bindings_2.o /tmp/emscripten_temp_OdtPcF/skottie_bindings_3.o /tmp/emscripten_temp_OdtPcF/SkottieUtils_4.o out/canvaskit_wasm/libskottie.a out/canvaskit_wasm/libsksg.a out/canvaskit_wasm/libparticles.a out/canvaskit_wasm/libskshaper.a out/canvaskit_wasm/libharfbuzz.a out/canvaskit_wasm/libicu.a out/canvaskit_wasm/libskia.a /tmp/emscripten_temp_OdtPcF/bind_5.o /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libfreetype.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libpng.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libz.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libcompiler_rt.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc-wasm.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc++-noexcept.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc++abi.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libc-extras.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libgl.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libdlmalloc.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libpthreads_stub.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a /home/rahulchaphalkar/.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 _ZSt18uncaught_exceptionv --export emscripten_builtin_memalign --export memalign --export emscripten_builtin_free --export _get_tzname --export _get_daylight --export _get_timezone --export _get_environ --export realloc --export emscripten_GetProcAddress --export strstr -z stack-size=5242880 --initial-memory=134217728 --no-entry --global-base=1024
wasm-ld: warning: function signature mismatch: _ZN9SkFontMgr10RefDefaultEv
>>> defined as (i32) -> void in out/canvaskit_wasm/libskottie.a(libskottie.TextLayer.o)
>>> defined as (i32) -> void in out/canvaskit_wasm/libskia.a(libskia.SkFontMgr.o)
 "/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/wasm-emscripten-finalize" /tmp/emscripten_temp_OdtPcF/canvaskit.wasm -o /tmp/emscripten_temp_OdtPcF/canvaskit.wasm.o.wasm --detect-features --global-base=1024 --initial-stack-pointer=5243904
Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf
shared:ERROR: '/home/rahulchaphalkar/wasm/emsdk/emsdk/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_OdtPcF/canvaskit.wasm -o /tmp/emscripten_temp_OdtPcF/canvaskit.wasm.o.wasm --detect-features --global-base=1024 --initial-stack-pointer=5243904' failed (1)

sbc100 commented 5 years ago

Can you look at how you build your libraries: out/canvaskit_wasm/libskottie.a out/canvaskit_wasm/libsksg.a out/canvaskit_wasm/libparticles.a out/canvaskit_wasm/libskshaper.a out/canvaskit_wasm/libharfbuzz.a out/canvaskit_wasm/libicu.a out/canvaskit_wasm/libskia.a /tmp/emscripten_temp_OdtPcF/bind_5.o /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libfreetype.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libpng.a /home/rahulchaphalkar/.emscripten_cache/wasm-obj/libz.a

Check that they are not using -fPIC when building?

rahulchaphalkar commented 5 years ago

I just checked, i couldn't see the fPIC flag anywhere being used for building the libraries. Is using/not using system libraries possibly related to this issue?

rahulchaphalkar commented 5 years ago

An FYI, this is compiling fine with the fastcomp llvm backend. Only when i switch to llvm upstream is when i get these issues.

sbc100 commented 5 years ago

Do you have a repro case for this?

pmp-p commented 5 years ago

@sbc100 i may have one repro case that @kripken would me to document here :

get micropython master + a pending PR https://github.com/micropython/micropython/pull/4875 for javascript port tweaked for raising the same bug with upstream

Here's the steps i followed :

cd /tmp
reset
git clone --recursive https://github.com/micropython/micropython.git
cd micropython/ && git submodule update --init
make -C mpy-cross
# use lastest-upstream from git
. /opt/sdk/emsdk-upstream/emsdk_env.sh 
wget https://github.com/micropython/micropython/pull/4875.diff -O-| patch -p1
make -C ports/javascript clean
emmake make -C ports/javascript SHARED=1

should lead to something like

[...]
CC main.c
CC mphalport.c
CC modutime.c
Linking static libmicropython.a
Linking shared libmicropython.wasm
Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf
shared:ERROR: '/opt/sdk/emsdk-upstream/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_X2UduX/libmicropython.wasm -o /tmp/emscripten_temp_X2UduX/libmicropython.wasm.o.wasm --detect-features --side-module' failed (1)
Makefile:159: recipe for target 'libs' failed
make: *** [libs] Error 1

from what i get it's caused by either SIDE_MODULE / MAIN_MODULE / -fPIC

sbc100 commented 5 years ago

Can you try with the very latest llvm. I'm hoping this will be fixed with: https://reviews.llvm.org/D65922

pmp-p commented 5 years ago

@sbc100 i'd gladly try to do that, but i have not clue where to begin with apart from git pull ; ./emsdk update-tags; ./emsdk install latest-upstream && ./emsdk activate latest-upstream in my emsdk git folder set on "master" branch

kripken commented 5 years ago

You can get a very recent llvm build using the tip-of-tree feature in the emsdk (that's how emscripten CI works). Do emsdk install tot-upstream etc. (i.e. replace latest-upstream with tot-upstream).

kripken commented 5 years ago

I confirmed that

emsdk update-tags
emsdk install tot-upstream
emsdk activate tot-upstream

gets LLVM that has that change.

pmp-p commented 5 years ago

thx, there's some changes but not so good ...

lib static + -fPIC that previously gave error: undefined symbol: fp$gc_collect$v now try to compile but clang crashes with

wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed. Stack dump: [...]

MAIN_MODULE + link lib static (SIDE_MODULE) + -fPIC => still Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf with

shared:ERROR: '/opt/sdk/emsdk-upstream/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_GtZl8V/micropython.wasm -o /tmp/emscripten_temp_GtZl8V/micropython.wasm.o.wasm --detect-features -g --input-source-map=/tmp/emscripten_temp_GtZl8V/micropython.wasm.map --output-source-map=/tmp/emscripten_temp_GtZl8V/micropython.wasm.o.wasm.map --output-source-map-url=http://localhost:8000/micropython.wasm.map --global-base=0' failed (1)

note to self: MAIN_MODULE + static (SIDE_MODULE) without -fPIC can't link because wasm-ld: error: build/py/nlr.o: relocation R_WASM_MEMORY_ADDR_LEB cannot be used against symbol mp_state_ctx; recompile with -fPIC

all static without -fPIC + asyncify has a 50% slowdown on a heavy duty blocking loop with no sleep() vs wasi-sdk 6 ( clang8 + node ) / fastcomp (v8/chromium). and a 150% slowdown vs no asyncify on latest-upstream ( but at least we'll have a working version (with no ffi) building correctly on upstream so that is not so bad ).
i'll try MAIN_MODULE + dlopen(SIDE_MODULE) shared later and report though it will probably only work on mozilla given the size of libmicropython.wasm.

edit/ how can i get the exact llvm revision emsdk used so i can give it with reports ?

was clang version 10.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 2346b92f2bff05ef9d83706787bd38e32e0079c5)

sbc100 commented 5 years ago

Ok, sorry I was a little confused. I thought you are trying to produce static build. I didn't realize you were interested in the MAIN_MODULE/SIDE_MODULE use case. I've replied below..

thx, there's some changes but not so good ...

lib static + -fPIC that previously gave error: undefined symbol: fp$gc_collect$v now try to compile but clang crashes with

wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed. Stack dump: [...]

Thats too bad, this is exactly the case I was hoping to have fixed. A fix for this should be easy if I can get a reasonable sizes repro.

MAIN_MODULE + link lib static (SIDE_MODULE) + -fPIC => still Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf with

shared:ERROR: '/opt/sdk/emsdk-upstream/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_GtZl8V/micropython.wasm -o /tmp/emscripten_temp_GtZl8V/micropython.wasm.o.wasm --detect-features -g --input-source-map=/tmp/emscripten_temp_GtZl8V/micropython.wasm.map --output-source-map=/tmp/emscripten_temp_GtZl8V/micropython.wasm.o.wasm.map --output-source-map-url=http://localhost:8000/micropython.wasm.map --global-base=0' failed (1)

OK this is the normal dynamic linking case and is almost certainly an emscripten or binaryen bug. Again should be easy enough to fix with a reasonable sized repro case. @kripken that symbol name looks familiar, isn't that the one that is double imported? I guess this is a binaryen bug.

note to self MAIN_MODULE + static (SIDE_MODULE) without -fPIC can't link because wasm-ld: error: build/py/nlr.o: relocation R_WASM_MEMORY_ADDR_LEB cannot be used against symbol mp_state_ctx; recompile with -fPIC

Thats right. All code in the main module and side module needs to be position independent (at least right now).

all static without -fPIC + asyncify has a 50% slowdown on a heavy duty blocking loop with no sleep() vs wasi-sdk 6 ( clang8 + node ) / fastcomp (v8/chromium). and a 150% slowdown vs no asyncify on latest-upstream ( but at least we'll have a working version (with no ffi) building correctly on upstream so that is not so bad ).

If I'm reading this right asynify is the problem here, no the llvm back end per-say? Perhaps worth opening a separate issue for that. I'm not sure if that expected or not.

i'll try MAIN_MODULE + dlopen(SIDE_MODULE) shared later and report though it will probably only work on mozilla given the size of libmicropython.wasm.

edit/ how can i get the exact llvm revision emsdk used so i can give it with reports ?

emcc -v should give you something like this:

clang version 10.0.0 (https://github.com/llvm/llvm-project.git 53093a574cfe4531f993ecc96451177eb1ef2cb6)

remoe commented 5 years ago

I had the same error on a different project. I changed to newest LLVM (032e1fdcd47ef98936c88aa30571c6a713179a46). After this it throws the following callstack:

wasm-ld: llvm-project.git/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed.

 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm-project.git/llvm/lib/Support/Unix/Signals.inc:532:0
 PrintStackTraceSignalHandler(void*) llvm-project.git/llvm/lib/Support/Unix/Signals.inc:593:0
 llvm::sys::RunSignalHandlers() llvm-project.git/llvm/lib/Support/Signals.cpp:68:0
 SignalHandler(int) llvm-project.git/llvm/lib/Support/Unix/Signals.inc:384:0
 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
 __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
 lld::wasm::Symbol::setGOTIndex(unsigned int) llvm-project.git/lld/wasm/Symbols.cpp:116:0
#lld::wasm::GlobalSection::assignIndexes() llvm-project.git/lld/wasm/SyntheticSections.cpp:243:0
#(anonymous namespace)::Writer::assignIndexes() llvm-project.git/lld/wasm/Writer.cpp:624:0
#(anonymous namespace)::Writer::run() llvm-project.git/lld/wasm/Writer.cpp:899:0
#lld::wasm::writeResult() llvm-project.git/lld/wasm/Writer.cpp:983:0
#(anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) llvm-project.git/lld/wasm/Driver.cpp:791:0
#lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) llvm-project.git/lld/wasm/Driver.cpp:95:0
#main llvm-project.git/lld/tools/lld/lld.cpp:159:0
#__libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
#_start (llvm-10.0/bin/wasm-ld+0x2f9b2a)

kripken commented 5 years ago

The longjmp name may indicate this is related to https://github.com/WebAssembly/binaryen/pull/2292 it's possible that fixes this issue too, as it removes the extra longjmp import which causes problems. The new 1.38.42 from today contains that fix, so trying there would see.

If that's not it, if you can provide a full testcase I can reproduce it with locally then I can debug that.

pmp-p commented 5 years ago

@kripken, i see no change with micropython codebase on 1.38.42-upstream

fail

MAIN_MODULE -fPIC +link lib static (SIDE_MODULE) + -fPIC MAIN_MODULE -fPIC +link lib static -fPIC

with

Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf
shared:ERROR: '/opt/sdk/emsdk-upstream/upstream/bin/wasm-emscripten-finalize /tmp/emscripten_temp_O9hwes/micropython.wasm -o /tmp/emscripten_temp_O9hwes/micropython.wasm.o.wasm --detect-features -g --input-source-map=/tmp/emscripten_temp_O9hwes/micropython.wasm.map --output-source-map=/tmp/emscripten_temp_O9hwes/micropython.wasm.o.wasm.map --output-source-map-url=http://localhost:8000/micropython.wasm.map --global-base=0' failed (1)
Makefile:327: recipe for target 'micropython.html' failed

fail

-fPIC +link lib static (SIDE_MODULE) + -fPIC

wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/lld/wasm/Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion `gotIndex == INVALID_INDEX' failed.
Stack dump:
0.  Program arguments: /opt/sdk/emsdk-upstream/upstream/bin/wasm-ld -o /tmp/emscripten_temp_2twO9B/micropython.wasm --allow-undefined --import-memory --import-table --lto-O0 /tmp/emscripten_temp_2twO9B/main_0.o libmicropython.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libSDL2.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libcompiler_rt.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc-wasm.a --whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc++abi.a --no-whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc-extras.a --whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libfetch.a --no-whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libgl.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libdlmalloc-debug.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libpthreads_stub.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libcompiler_rt_wasm.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc_rt_wasm.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --export-all -z stack-size=16777216 --initial-memory=671088640 --no-entry --max-memory=671088640 --global-base=1024 
 #0 0x00007f6b676499f4 PrintStackTraceSignalHandler(void*) (/opt/sdk/emsdk-upstream/upstream/bin/../lib/libLLVM-10svn.so+0x6d79f4)
 #1 0x00007f6b6764773e llvm::sys::RunSignalHandlers() (/opt/sdk/emsdk-upstream/upstream/bin/../lib/libLLVM-10svn.so+0x6d573e)
 #2 0x00007f6b67649ca8 SignalHandler(int) (/opt/sdk/emsdk-upstream/upstream/bin/../lib/libLLVM-10svn.so+0x6d7ca8)
 #3 0x00007f6b6a51b390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
 #4 0x00007f6b6631f428 raise /build/glibc-LK5gWL/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
 #5 0x00007f6b6632102a abort /build/glibc-LK5gWL/glibc-2.23/stdlib/abort.c:91:0
 #6 0x00007f6b66317bd7 __assert_fail_base /build/glibc-LK5gWL/glibc-2.23/assert/assert.c:92:0
 #7 0x00007f6b66317c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
 #8 0x00000000006ac4fb (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x6ac4fb)
 #9 0x00000000006c691b lld::wasm::GlobalSection::assignIndexes() (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x6c691b)
#10 0x00000000006b1466 (anonymous namespace)::Writer::run() (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x6b1466)
#11 0x00000000006adaaf lld::wasm::writeResult() (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x6adaaf)
#12 0x0000000000690ae7 (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x690ae7)
#13 0x000000000068b6d8 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x68b6d8)
#14 0x000000000041eadb main (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x41eadb)
#15 0x00007f6b6630a830 __libc_start_main /build/glibc-LK5gWL/glibc-2.23/csu/../csu/libc-start.c:325:0
#16 0x000000000041e669 _start (/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld+0x41e669)
shared:ERROR: '/opt/sdk/emsdk-upstream/upstream/bin/wasm-ld -o /tmp/emscripten_temp_2twO9B/micropython.wasm --allow-undefined --import-memory --import-table --lto-O0 /tmp/emscripten_temp_2twO9B/main_0.o libmicropython.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libSDL2.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libcompiler_rt.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc-wasm.a --whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc++abi.a --no-whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc-extras.a --whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libfetch.a --no-whole-archive /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libgl.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libdlmalloc-debug.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libpthreads_stub.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libcompiler_rt_wasm.a /opt/sdk/emsdk-upstream/EM_CACHE/wasm-obj/libc_rt_wasm.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --export-all -z stack-size=16777216 --initial-memory=671088640 --no-entry --max-memory=671088640 --global-base=1024' failed (-6)
Makefile:326: recipe for target 'micropython.html' failed

not possible atm

( see R_WASM_MEMORY_ADDR_LEB as @sbc100 said earlier )

MAIN_MODULE +link lib static (SIDE_MODULE) + -fPIC MAIN_MODULE +link lib static (SIDE_MODULE) complete static linking with -s MAIN_MODULE=1

ok but crippled for ffi/dlopen

complete static linking.

last case is probably fine from MicroPython point of view but that would not be very constructive for emsdk future. so to reproduce need to add experimental port https://github.com/pmp-p/micropython-ports-wasm. into port folder of micropython master and using ./repro.sh XXX=1 there are 3 test cases with SHARED=1 / STATIC=1 / WHOLE=1

( STATIC=1 at least would be great since small dlopened wasm python modules are wanted , not a problem for libmicropython.wasm not shared since it's too big for some browsers )

clang version 10.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project edfaee08115376467d1c95573de991aebfdaeb42)

Shachlan commented 5 years ago

Using the tot-upstream branch, I see that the same issue still happens with skia's Canvaskit. archives are created without indices, and after manually adding the indices using ranlib, the following error is returned:

0 0x00007f727dba0724 PrintStackTraceSignalHandler(void*) (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e2724)

1 0x00007f727db9e46e llvm::sys::RunSignalHandlers() (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e046e)

2 0x00007f727dba09d8 SignalHandler(int) (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e29d8)

3 0x00007f7280aabf40 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13f40)

4 0x00007f727cfcced7 raise (/lib/x86_64-linux-gnu/libc.so.6+0x43ed7)

5 0x00007f727cfae535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25535)

6 0x00007f727cfae40f (/lib/x86_64-linux-gnu/libc.so.6+0x2540f)

7 0x00007f727cfbe012 (/lib/x86_64-linux-gnu/libc.so.6+0x35012)

8 0x00000000006b5c3b (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6b5c3b)

9 0x00000000006d005b lld::wasm::GlobalSection::assignIndexes() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6d005b)

10 0x00000000006baba6 (anonymous namespace)::Writer::run() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6baba6)

11 0x00000000006b71ef lld::wasm::writeResult() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6b71ef)

12 0x000000000069a267 (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) (/render/third_party/emsdk/upstream/bin/wasm-ld+0x69a267)

13 0x0000000000694e58 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/render/third_party/emsdk/upstream/bin/wasm-ld+0x694e58)

14 0x000000000041e8eb main (/render/third_party/emsdk/upstream/bin/wasm-ld+0x41e8eb)

15 0x00007f727cfafb6b __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6b)

16 0x000000000041e479 _start (/render/third_party/emsdk/upstream/bin/wasm-ld+0x41e479)

shared:ERROR: '/render/third_party/emsdk/upstream/bin/wasm-ld -o /tmp/emscripten_temp_vh3AaM/canvaskit.wasm --allow-undefined --import-memory --import-table --lto-O2 /tmp/emscripten_temp_vh3AaM/canvaskit_bindings_0.o /tmp/emscripten_temp_vh3AaM/particles_bindings_1.o /tmp/emscripten_temp_vh3AaM/skottie_bindings_2.o /tmp/emscripten_temp_vh3AaM/SkottieUtils_3.o out/canvaskit_wasm/libskottie.a out/canvaskit_wasm/libsksg.a out/canvaskit_wasm/libparticles.a out/canvaskit_wasm/libskshaper.a out/canvaskit_wasm/libharfbuzz.a out/canvaskit_wasm/libicu.a out/canvaskit_wasm/libskia.a /root/.emscripten_cache/wasm-obj/libfreetype.a /root/.emscripten_cache/wasm-obj/libpng.a /root/.emscripten_cache/wasm-obj/libz.a /root/.emscripten_cache/wasm-obj/libc.a /root/.emscripten_cache/wasm-obj/libcompiler_rt.a /root/.emscripten_cache/wasm-obj/libc-wasm.a /root/.emscripten_cache/wasm-obj/libc++-noexcept.a /root/.emscripten_cache/wasm-obj/libc++abi.a /root/.emscripten_cache/wasm-obj/libc-extras.a --whole-archive /root/.emscripten_cache/wasm-obj/libembind-rtti.a --no-whole-archive /root/.emscripten_cache/wasm-obj/libgl.a /root/.emscripten_cache/wasm-obj/libdlmalloc.a /root/.emscripten_cache/wasm-obj/libpthreads_stub.a /root/.emscripten_cache/wasm-obj/libcompiler_rt_wasm.a /root/.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 _ZSt18uncaught_exceptionv --export emscripten_builtin_memalign --export memalign --export emscripten_builtin_free --export _get_tzname --export _get_daylight --export _get_timezone --export _get_environ --export realloc --export emscripten_GetProcAddress --export strstr -z stack-size=5242880 --initial-memory=134217728 --no-entry --global-base=1024' failed (-6)

In order to repro, the skia repo can be cloned and call the modules/canvaskit/compile.sh script.

sbc100 commented 5 years ago

@Shachlan I'm looking at the crash now.

BTW the ranlib issue can be solved by adding EMAR=`which emar` to your script at passing ar=\"${EMAR}\" to gn.

Also src/core/SkContourMeasure.cpp seems to have a float to int conversion warning const SkScalar kMaxTReciprocal = 1.0f / kMaxTValue;. Once I fixed that I repro'd your crash.

Shachlan commented 5 years ago

Thanks @sbc100! Is there anything I can do to help with the investigation?

sbc100 commented 5 years ago

Fix is in progress in https://reviews.llvm.org/D66784. Its not ready yet but I've found the issue.

sbc100 commented 5 years ago

IIUC the remaining issues you are seeing here are a duplicate of #9317. If I'm correct lets close this one in favor of 9217

sbc100 commented 5 years ago

The fix for the signature mismatch warnings is here: https://reviews.llvm.org/D67015

Shachlan commented 5 years ago

Thanks @sbc100 ! Any news on the -fPIC static linking issue?

pmp-p commented 5 years ago

@Shachlan look at https://github.com/emscripten-core/emscripten/issues/9317#issuecomment-526873259 and earlier for how @beuc managed to test proposed patches, sadly i have very bad internet and can't get 70 GiB of stuff to test https://reviews.llvm.org/D67015

sbc100 commented 5 years ago

Not yet. For now I still recommend trying to remove fPIC from your compile commands.

sbc100 commented 5 years ago

D67015 is not ready yet

kripken commented 5 years ago

Looks like D67015 landed in LLVM, can this be closed?

(If so, do we have tests for this now?)

sbc100 commented 5 years ago

D67015 only fixes the spurious signature mismatches. I think the other issue which manifests as Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): AssertiongotIndex == INVALID_INDEX' failed.` is yet to be fixed.

However that issue is better described in #9317. So closing this now as duplicate of that issue.

Shachlan commented 5 years ago

Thanks! When do you think it will be integrated for consumption via emsdk?

sbc100 commented 5 years ago

What issue are you asking about?

The spurious signature mismatches issue is already available I latest I believe. As is the Fatal: GOT.func entry with no import/export issue I believe.

The only remaining issue is #9317 (Symbols.cpp:115: void lld::wasm::Symbol::setGOTIndex(uint32_t): Assertion) and we don't have a fix for that yet.

Shachlan commented 5 years ago

Thanks, I was referring to the D67015 fix, but I seem to have misunderstood how emsdk works - I wrongly assumed that fixes to emscripten need to be also merged into emsdk.

sbc100 commented 5 years ago

We do need to cut a new emscripten release before you will see any changes appear in emsdk.

To find out what is in a given release Is a sadly fairly involved procedure: You start by looking at: https://github.com/emscripten-core/emsdk/blob/master/emscripten-releases-tags.txt

Those hashs are revisions in https://chromium.googlesource.com/emscripten-releases/+/refs/heads/master/.

To see what is in 1.38.45 you can look at the DEPS file at that revision: https://chromium.googlesource.com/emscripten-releases/+/f3030d9fffcc9e1287cb6b8e72982e94ece31d71/DEPS

There you see llvm revision: f145456fc4a4a9938630daab41969da2be8208db

And this revisions does indeed include https://reviews.llvm.org/D67015.

Phew.. thats harder than it should be..

pmp-p commented 5 years ago

i fear MAIN_MODULE static build with -fPIC problem is not solved and both #9317 #8995 are closed is there something more accurate for that particular matter to follow ?

sbc100 commented 5 years ago

I believe all the the issues that have been raise are now fixed in upstream llvm. What issues do you have the remain? Is this issue still occurring for you with the latest llvm?

pmp-p commented 5 years ago

i triplechecked for SIDE MODULE not being present, added -fPIC everywhere

but wasm-ld failed at program linking and don't have much other clue than

wasm-ld: error: duplicate symbol: fprintf
            defined in /opt/sdk/emsdk-upstream/.emscripten_cache/wasm-obj/libc.a(fprintf.c.o)
            defined in /opt/sdk/emsdk-upstream/.emscripten_cache/wasm-obj-pic/libc.a(fprintf.c.o)

the linker line seems perfectly legit https://wyz.fr/paste/5JB/raw. but MAIN_MODULE=1 pulls wasm-obj-pic/libc.a while -lc wants to pull the non pic ones ( emcc with -static or not ).

removing either of those will not solve the dl* functions requirements i have for FFI.

Pipeline was : a bunch of .o => lib.a with $(AR) rcs $(LIBMICROPYTHON) $(OBJ) => emcc -s MAIN_MODULE=1 -static -o program.html main.c lib.a -ldl -lm -lc

note that i don't have control on .o compilation but i can extract info if needed.

Is this issue still occurring for you with the latest llvm?

i'll retry with tot-upstream in a few hours, but problem was already there few days before kripken asked for the go of tagging,

btw is it ok to open issues for tot-upstream ? or better address someone specific on IRC for that, as i only reported on IRC ( i'm rarely sure of my findings all of that is very experimental for me ):

- {Day changed to Sunday, September 22, 2019}
<-- vanjavk (vanjavk@moz-tdcofb.dsl.iskon.hr) has quit (Ping timeout: 121 seconds)
<pmp-p> tot-upstream:  embuilder.py build --pic sdl2  => "wasm-ld: error: -r and -pie may not be used together"
<pmp-p> tot-upstream: EXPORTED_FUNCTIONS is broken
<pmp-p> but adding an EM_ASM block with ref to exported functions in array, fix it and re exports them

sbc100 commented 5 years ago

OK, so the "linking two different copies of libc" looks like real and seperate issue. Could you open a bug for that?

The SDL2 issue (-pie + -r) was fixed in #9510

IRC is a fine place to discuss issues, but I for one might not see it unless you mention me there. If nobody gets back to you feel free to open issues here.

hugoam commented 4 years ago

I can still produce the original error in this issue with latest version (1.39.5) Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf This happens when building a whole bunch of libraries with -s MAIN_MODULE=1 -fPIC, archiving them with emar into a range of .bc intermediary modules, and then linking those into a .wasm library Probably related to https://github.com/emscripten-core/emscripten/issues/9950

emscripten-core / emscripten

Wasm compilation error "Fatal: GOT.func entry with no import/export" when running wasm-emscripten-finalize #8995

fail

fail

not possible atm

ok but crippled for ffi/dlopen

0 0x00007f727dba0724 PrintStackTraceSignalHandler(void*) (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e2724)

1 0x00007f727db9e46e llvm::sys::RunSignalHandlers() (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e046e)

2 0x00007f727dba09d8 SignalHandler(int) (/render/third_party/emsdk/upstream/bin/../lib/libLLVM-10svn.so+0x6e29d8)

3 0x00007f7280aabf40 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13f40)

4 0x00007f727cfcced7 raise (/lib/x86_64-linux-gnu/libc.so.6+0x43ed7)

5 0x00007f727cfae535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25535)

6 0x00007f727cfae40f (/lib/x86_64-linux-gnu/libc.so.6+0x2540f)

7 0x00007f727cfbe012 (/lib/x86_64-linux-gnu/libc.so.6+0x35012)

8 0x00000000006b5c3b (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6b5c3b)

9 0x00000000006d005b lld::wasm::GlobalSection::assignIndexes() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6d005b)

10 0x00000000006baba6 (anonymous namespace)::Writer::run() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6baba6)

11 0x00000000006b71ef lld::wasm::writeResult() (/render/third_party/emsdk/upstream/bin/wasm-ld+0x6b71ef)

12 0x000000000069a267 (anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) (/render/third_party/emsdk/upstream/bin/wasm-ld+0x69a267)

13 0x0000000000694e58 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/render/third_party/emsdk/upstream/bin/wasm-ld+0x694e58)

14 0x000000000041e8eb main (/render/third_party/emsdk/upstream/bin/wasm-ld+0x41e8eb)

15 0x00007f727cfafb6b __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6b)

16 0x000000000041e479 _start (/render/third_party/emsdk/upstream/bin/wasm-ld+0x41e479)