WASM usage (and general cross-compiling issue)

[s5bug]

As of now, it's impossible to (easily, automatically) build this crate for usage on the web (or on any target other than the host machine).

The first problem you will run into is <stdlib.h> and <complex.h> not being defined.

1. The first should be solved by making qiskit's cbindgen (in qiskit, not qiskit-rs) not include the standard includes: it doesn't look like qiskit.h needs anything from stdlib.h.
2. The second can be solved with a simple fill assuming GCC/clang:

#if !__has_include(<complex.h>)

#define complex _Complex
#define _Complex_I ((_Complex float)__builtin_complex((float)0.0, (float)1.0))
#define I _Complex_I
#define creal(x) (__real__(x))
#define cimag(x) (__imag__(x))

#endif

After this, one will find that bindgen (in qiskit-rs, not qiskit) does not generate forwarders for the C functions. This is because qiskit-sys just builds qiskit using make, which uses the system compiler instead of the correct compiler for the target.

The recommended solution as far as I know is to use the cc crate as a build-dependency, and not use the Makefile at all, but I simply don't have the energy right now to try and get that working.

[emilkovacev]

Hi @s5bug, thanks for opening this issue! I've been trying to pull a few threads together to see if wasm support in qiskit-rs is feasible, here are some updates:

After this, one will find that bindgen (in qiskit-rs, not qiskit) does not generate forwarders for the C functions. This is because qiskit-sys just builds qiskit using make, which uses the system compiler instead of the correct compiler for the target.

I worked on a fix for the build process in qiskit-sys to attempt to enable this workflow, source is here. This swaps the Make call with a call to the qiskit-c-api build library, passing the target similar to how Qiskit/qiskit#15484 would.

That being said, I was not able to successfully build qiskit-sys with the wasm32-unknown-unknown target, since a core dependency within qiskit, (atomic-wait), does not yet have wasm support.

[s5bug]

@emilkovacev there's two ways to go here:

1. don't use wasm threads, in which case maybe atomic-wait isn't needed?
2. use wasm threads, in which case wasm has u32.atomic.wait which should be enough to implement atomic-wait

this fork seems to have done (2).