Gyeongjae Choi

Closing as completed.

I think `clapack_all.so` is loaded but it is not loaded with `global: true` so the symbol is not resolved. Probably we need to load libraries in `DSO_DIR` with `global: true`...

[`loadDynlib`](https://github.com/pyodide/pyodide/blob/f8c6b8ade60f5d349c1c8b8487c772b4893759f6/src/js/dynload.ts#L96) loads dependencies too, so if shared libraries of scipy are linked with `clapack_all.so` then it will be loaded. So I think you can try setting `global` argument to true...

> doesn't work with the cloned GitHub repository and returns the error message What happens if you build from the sdist in the PyPI?

> That issue is now closed, and it says that the fix was released in Emscripten 3.1.34. The current version used in Pyodide is higher (3.1.46 in the scikit-image build)....

I see. Looking at the swig/python/CMakeLists.txt file, it seems that `PYTHON_INCLUDE_PATH` (or `PYTHON_INCLUDE_DIR)` is being entered with the wrong value: https://github.com/casadi/casadi/blob/70f5cc19a288a1e753d06670060d2563aa63fafa/swig/python/CMakeLists.txt#L37-L63

`PYTHON_INCLUDE_DIR` is passed in setup.py here: https://github.com/casadi/casadi/blob/70f5cc19a288a1e753d06670060d2563aa63fafa/swig/python/setup.py.in#L46-L53 I think you need to overwrite it with the include dir under the xbuildenv, which will be under `.pyodide-xbuildenv/xbuildenv/pyodide-root/cpython/installs/python-3.11.3/include/python3.11` (assuming that you are...

> can we decide whether forceGlobal should be true based on whether the dynamic library is not installed in site-packages? So that it's loaded globally if it's in neededDylibs or...

Seems like this (https://github.com/emscripten-core/emscripten/pull/21985) was related to this issue. I'll take a look soon.

One blocker for that usage is that Pyodide [doesn't support synchronous I/O](https://pyodide.org/en/stable/project/roadmap.html#synchronous-io) for now. But I think you can try asynchronous libraries such as aiomysql to mitigate it.