Is it possible to make export_bindings work for WASI targets?

[josephwynn-sc]

One of our backends is built on Fastly's Rust SDK, which is only built for WASI targets. I cannot run export_bindings with the host target because the linker fails with

Undefined symbols for architecture arm64

I also cannot run export_bindings with the default wasm32-wasip1 target because it fails with:

could not export type: Io(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/\" could be opened" })

Am I missing an obvious solution here? Is there any way ts-rs could get around WASI's lack of filesystem implementation?

[NyxCode]

Interesting issue!
Off the top of my head, I can't think of a solution other than to set the target manually via cargo t export_bindings --target x86_64-???.

[josephwynn-sc]

Thanks for the response! Sorry I should have been clearer - I am unable to run export_bindings against with my host target because the Fastly SDK used in my project can only build for WASI targets. The output for other targets looks something like:

$ cargo test export_bindings --target aarch64-apple-darwin
error: linking with `cc` failed: exit status: 1
  = note: Undefined symbols for architecture arm64:
            "_append", referenced from:
                fastly::http::body::handle::BodyHandle::append::hdcd485339dc553f2 in libfastly-701ddb35c3fccf53.rlib[18](fastly-701ddb35c3fccf53.fastly.2651ba793b16c7e1-cgu.15.rcgu.o)
            "_body_downstream_get", referenced from:
                fastly::http::request::handle::client_request_and_body::h6288c831bad6dbf5 in libfastly-701ddb35c3fccf53.rlib[18](fastly-701ddb35c3fccf53.fastly.2651ba793b16c7e1-cgu.15.rcgu.o)
            "_endpoint_get", referenced from:
                fastly::log::Endpoint::try_from_name::h3841623e8682e903 in libfastly-701ddb35c3fccf53.rlib[18](fastly-701ddb35c3fccf53.fastly.2651ba793b16c7e1-cgu.15.rcgu.o)
            "_framing_headers_mode_set", referenced from:
                fastly::http::response::handle::ResponseHandle::set_framing_headers_mode::h9337cdefb69588b1 in libfastly-701ddb35c3fccf53.rlib[18](fastly-701ddb35c3fccf53.fastly.2651ba793b16c7e1-cgu.15.rcgu.o)
            "_get", referenced from:

            [... snip]

Something else I could try is importing my types into another "empty" project (i.e. without the Fastly SDK) that can be built for the host target.

[NyxCode]

Oh, that's particularly annoying. We need some way to actually run tests locally, with access to the filesystem. No way around that.

Splitting your crate into two (types and api) should work, if that's acceptable to you.

Besides that, maybe there is some way to get filesystem access when running the thing with the fastly CLI. I have never used it, so I have no idea why it doesn't work by default and what you'd need to do to make it work.

Also, you could find some other way to get the bindings out of the running binary - maybe by writing them to stdout by calling TS::export_to_string on all types yourself. For this, we might be able to offer a better API in the future - e.g by writing to stdout instead of the FS if a cargo feature is enabled.

[josephwynn-sc]

Ahh I had no idea about export_to_string()! This is perfect, thanks so much :)