pe^cjo

One step closer! I think the shared library works now, but InSpice can't call it yet. To be continued.

Pyodide is just Python compiled using Emscripten, and can be tried here: https://pyodide.org/en/stable/console.html Meanwhile I have found that passing --host=wasm32-unknown-emscripten will trigger libtool to pass the right flags to make a shared library on wasm. However, this uses mode two that only includes explicitly exported symbols, so I've developed a patch to export the shared API: https://github.com/pepijndevos/pyodide/blob/ngspice/packages/ngspice/patches/0001-keep-alive-API-functions.patch...

it looks like libtool should have dedicated support for emscripten that should hide all the linking details as intended: https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=d8a934458b251b465b7d31da9ba9148a128a146d so maybe the problem is rather that we're not using emscripten libtool? this might be related: https://sourceforge.net/p/ngspice/patches/100/

i indeed tried the same change to pass cflags and ldflags like you mentioned with no effect. are you suggesting to do a dry-run build to essentially generate a script, and then sed the script to inject the linker flag? that sounds properly hacky. i don't know anything about libtool but you'd think surely there is a better way.

The basic procedure is to wrap your build steps, which sets up the build with extra variables and parameters to use the emscripten compiler. From my Pyodide recipe: emconfigure ../configure "${configure_args[@]}" CFLAGS="${SIDE_MODULE_CFLAGS}" emmake make -j ${PYODIDE_JOBS:-3} LDFLAGS="${SIDE_MODULE_LDFLAGS}" The complication seems to be that Emscripten has a unusual way of dealing with system libraries and preferring static linking combined with aggressive dead code elimination, and by default generates...

When I said python, I meant Pyodide, so Python compiled to WASM, so you can run simulations in a WASM notebook like Marimo. I can run ImSpice in Pyodide, which supports both the shared library interface as well as the binary interface. The advantage of the shared library is that it allows for streaming results. But if compiling as a binary is significantly easier than as a shared library I could use that.

Yes I saw your project, which is really impressive. I want to use it as a python library though. Are you using ngspice as a binary? InSpice also supports the binary interface so if that works I may just abandon the shared library approach and use the more primitive binary interface. But I'd like to think with some build system massaging it should be possible to make a working libngspice.so like any other well behaved C library.

Idk, emscripten has a page about it: https://emscripten.org/docs/compiling/Dynamic-Linking.html The linked PR should have a pretty good summary of what I'm trying to do and what goes wrong: I want to make an ngspice package for Pyodide you you can use it with libraries like PySpice/InSpice that load libngspice.so with cffi. It is currently giving an error: The following error occurred while loading ngspice: need the dylink section to be first Which the Pyodide maintainers say is because you need...