[Uno.Wasm.Bootstrap] Enable emscripten dynamic linking

[Beyley]

Upon attempting to call dlopen/dlsym, i get an exception stating to enable dynamic linking in empscripten, but when attempting to do so like how the emscripten docs say to, i get an exception on build, and looking at the binlog, it seems that theres conflicting symbol exports, i think since -sMAIN_MODULE exports everything.
https://emscripten.org/docs/compiling/Dynamic-Linking.html
binlog.in.a.zip

test code here

[jeromelaban]

Dynamic linking is not supported by Uno at this time, it's also not supported by the .NET runtime in general. We tried supporting it in the past, and it was very difficult to get right.

Static linking is the only available route for .NET at this point.

Why do you need dlopen to work?

[Beyley]

Silk.NET does not have codepaths for direct DllImport, its all loaded as function pointers using various operating system things (like dlopen/dlsym on linux or whatever windows has, or the platform agnostic way dotnet core has, if available)
Im actually able to get Silk.NET functions to work perfectly if i manually DllImport a function in my code, and call it at least once, that makes NativeLibrary3.TryGetExport work flawlessly, meaning the Silk codepath is happy and i can call the silk.net function

Is there some workaround/codepath i need to implement into Silk here? like compile flags to make NativeLibrary3.TryGetExport work without needing to manually DllImport too

[jeromelaban]

WebAssembly code is not able to arbitrarily invoke functions like native code can. The effect of this security feature is that .NET needs to know in advance what needs to be called, and this is done through scanning for DllImportAttribute marked methods.

As a result, for Silk.NET to work, there needs to be a corresponding DllImport for each native import called. It could be generated by the Silk.NET team, or by yourself using a source generator that scans all the APIs provided by the GL class.

[Beyley]

WebAssembly code is not able to arbitrarily invoke functions like native code can. The effect of this security feature is that .NET needs to know in advance what needs to be called, and this is done through scanning for DllImportAttribute marked methods.

As a result, for Silk.NET to work, there needs to be a corresponding DllImport for each native import called. It could be generated by the Silk.NET team, or by yourself using a source generator that scans all the APIs provided by the GL class.

Ah, i was hoping there was some manual override that wouldnt require a bunch of dead weight in the assembly, something like <WasmShellAdditionalPInvokeLibraryFunctions Include="SDL_Init" /> to specify what functions to include without needing DllImports, but if that does not exist, i can make the Silk generator output a separate package that only contains a bunch of private DllImports that dont do anything