================
@@ -711,6 +712,14 @@ llvm::Error Interpreter::Undo(unsigned N) {
}
llvm::Error Interpreter::LoadDynamicLibrary(const char *name) {
+#ifdef __EMSCRIPTEN__
+ void *handle = dlopen(name, RTLD_NOW | RTLD_GLOBAL);
+ if (!handle) {
+ llvm::errs() << dlerror() << '\n';
+ return llvm::make_error<llvm::StringError>("Failed to load dynamic
library",
+ llvm::inconvertibleErrorCode());
+ }
+#else
----------------
anutosh491 wrote:
Additionally, path resolution isn't a concern in the wasm case for a few
reasons (which is why a simple combination of dlopen + dlsym should do the job
isn't it ?)
1) All dynamic libraries are preloaded into MEMFS at known paths during
compilation or initialization (e.g., via Emscripten’s --preload-file flag).
This means the library’s location is fully deterministic at runtime.
2) No concept of system-level search paths like LD_LIBRARY_PATH in the browser
— we can’t rely on an OS-level dynamic loader. Instead, we always load by the
full path (e.g., dlopen("/libsymengine.so")), which resolves directly in the
virtual MEMFS.
3) Because users control the preload path, and because dlopen in Emscripten
expects an exact match in the in-memory filesystem, we don’t need
infrastructure for path lookup, search path prioritization, or
canonicalization. A simple, direct path-based dlopen is all that’s required.
https://github.com/llvm/llvm-project/pull/133037
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
