Skip to content

[Feature Request]: Discuss the move to static instead of shared build for wasm use cases #493

Open
@anutosh491

Description

@anutosh491

Description of new feature

Hey All,

Currently we have a decent shared wasm build for cppinterop. By decent I mean the following

i) somewhat optimized, takes around 15 mins to build
ii) Not too shabby and clear of obvious warnings
iii) Xeus-cpp-lite build time is not too long takes around 1 min 10 seconds using libclangCppInterOp.so
iv) After introducing the following lines in xeus-cpp, Jupyterlite knows we xeus-cpp needs access to libclangCppInterOp.so at runtime and hence there hasn't been any issues running stuff with latest jupyterlite-core

But the general notion with emscripten is that static libs are generally preferred. Pyodide and emscripten-forge avoid shared libraries as much as possible and only use them if the static build doesn't work. Infact, Cmake + emscripten don't even provide a way to generate a shared build. Read emscripten-core/emscripten#15276

So we introduce a work around to get our shared builds. Hence as move to emsdk 3.1.73 (through #456) we should be able to generate a static build (which was not possible with 3.1.45 ... check llvm/llvm-project#114651)

But there is things to discuss before we do that

  1. Build time and how optimized can it be
  2. Use cases (if it helps us do more stuff than the shared build)
  3. Build time for xeus-cpp-lite
  4. Runtime delays in loading the interpreter and running code cells (as Jupyterlite is compatible with fetching archives we won't have to explicitly tell it to look for libclangInterpreter.a like we do currently for libclangCppInterOp.so)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions