Remove 'getDylinkMetadata' from exported methods

[davy39]

I tried to build xeus-ocaml with Emscripten 4x, but it throws error with undefined method.

It may be redundant with MAIN_MODULE=1

Anyway, without it it builds and works fine, and and so does it with emscripten 3.73.

[DerThorsten]

For emscripten-4x experiments I used my personal branch where I also removed it
main...DerThorsten:xeus:emscripten4x

Not 100% sure if we can remove it for 3.1.73. I assume xeus-ocaml does not try to load any dlopen at runtime, and historically we need that getDylinkMetadata symbol when using dlopen.

[JohanMabille]

Arf I was too eager to merge and did it before you edit your comment. Anyway, since it was preventing a kernel to build, let's keep it as is, and we can still fix downstream kernels by adding this method in the post.js file.

[DerThorsten]

@davy39 btw for emscripten-4x we switch to -f-wasm-exceptions, so even with that PR here landed, you still cannot use the main branch for emscripten-4x.

[davy39]

@davy39 btw for emscripten-4x we switch to -f-wasm-exceptions, so even with that PR here landed, you still cannot use the main branch for emscripten-4x.

I did build without it, but I'll keep that in mind, and maybe make a new new branch for 4x

[DerThorsten]

@davy39 btw for emscripten-4x we switch to -f-wasm-exceptions, so even with that PR here landed, you still cannot use the main branch for emscripten-4x.

I did build without it, but I'll keep that in mind, and maybe make a new new branch for 4x

I assume it works if you also not use -f-wasm-exeptions in your kernel, but one of the goals of the 4x migration is to use -f-wasm-exeptions everywhere

[davy39]

OK, I think I'll just wait for xeus and xeus-lite from emscripten-forge-4x to include -f-wasm-exeptions to see the difference.

[DerThorsten]

@davy39 there is already that channel for emscripten-forge-4x https://prefix.dev/channels/emscripten-forge-4x
For that experimental channel, I used my forks / branches for emscripten-4x which already use -f-wasm-exceptions. But all of that is not very stable yet.

[davy39]

I've seen this channel coming from emscripten-4x branch.
The thing is that xeus and xeus-lite from this channel still include WasmBuildOptions.cmake and ...Targets.cmake with -fexceptions.
So I won't get -fwasm-exceptions by building xeus-ocaml against them.

[DerThorsten]

@davy39 damn you are right...thats a bug...I think when I compiled my xeus-python prototype with -f-wasm-exceptions I just not included these options in the xeus-python kernel.
I'll delete these packages and will uploaded fixed ones soonish

[DerThorsten]

@davy39 I just deleted the broken pkgs and uploaded

xeus-5.2.3-h0b0027f_5.tar.bz2
xeus-lite-4.0.0-h0b0027f_3.tar.bz2

I checked the targets and wasm-options, they are now using -fwasm-exceptions!

[davy39]

Just sharing experience :
First it didn't build due to the lack of --bind flag in new WasmBuildOptions.cmake.
Adding that flag in my CMakeLists fixes the build, but then my kernel fails with
Error: Dynamic linking error: cannot resolve symbol invoke_ii

That's beyond my understanding...

[DerThorsten]

Just sharing experience : First it didn't build due to the lack of --bind flag in new

I removed that while making xeus-python work, since there and handled that in the kernel itself

WasmBuildOptions.cmake. Adding that flag in my CMakeLists fixes the build, but then my kernel fails with Error: Dynamic linking error: cannot resolve symbol invoke_ii

That's beyond my understanding...

That means your kernel drags in -fexceptions instead -fwasm-exceptions

[davy39]

Could that's be because of my javascript --pre-js xocaml.bc.js ?

[DerThorsten]

I think you need to pass -f-wasm-exception as compile and linker arg in the kernel