This PR partially rollbacks #961 related to cross-compilation...

I see. According to the target_env docs:

For historical reasons, this value is only defined as not the empty-string when actually needed for disambiguation.

I can see why this is empty when using wasm32-wasi as the target. I can't check this PR makes wasm32-wasi compilation possible, since it's not working for me for other reasons. But I can verify that clang is not being called with the flags defined in build.rs and that the relevant code block is being skipped.

I see. According to the target_env docs:

For historical reasons, this value is only defined as not the empty-string when actually needed for disambiguation.

I can see why this is empty when using wasm32-wasi as the target. I can't check this PR makes wasm32-wasi compilation possible, since it's not working for me for other reasons. But I can verify that clang is not being called with the flags defined in build.rs and that the relevant code block is being skipped.

Maybe we should check both ?

        if env::var("TARGET") == Ok("wasm32-wasi".to_string()) || is_compiler("wasm32-wasi") {

I've the same change in a local fork of rusqlite. It builds fine, but it isn't running. The error it throws is:

WebAssembly.instantiate(): Import #1 module=\"env\" function=\"sqlite3_os_init\" error: function import requires a callable

This, however, is expected, as the docs state:

Applications must also supply implementations for the sqlite3_os_init() and sqlite3_os_end() interfaces. The usual practice is for the supplied sqlite3_os_init() to invoke sqlite3_vfs_register(). SQLite will automatically invoke sqlite3_os_init() when it initializes.

This is why I also had to define my own sqlite3_os_init in my project (that uses rusqlite). A minimal sqlite3_os_init would look something like:

#[no_mangle]
extern "C" fn sqlite3_os_init() -> i32 {
    ffi::sqlite3_vfs_register(CUSTOM_VFS, false as i32)
}

@rkusa Have you enabled the wasm32-wasi-vfs feature? There is a VFS with sqlite3_os_init included for wasi, but it's gated behind that feature:

@trevyn Good call, wasm32-wasi-vfs indeed fixes the error and does not require to provide a custom sqlite3_os_init. However, in my particular use-case, where I am going to use a custom VFS, and where I want to keep the amount of WASI imports low, I am better of keeping the feature disabled. Because the feature requires the following WASI imports, which are not necessary otherwise:

"wasi_snapshot_preview1"."fd_close": [I32] -> [I32]
"wasi_snapshot_preview1"."fd_fdstat_get": [I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_filestat_get": [I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_prestat_get": [I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_prestat_dir_name": [I32, I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_read": [I32, I32, I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_seek": [I32, I64, I32, I32] -> [I32]
"wasi_snapshot_preview1"."fd_sync": [I32] -> [I32]
"wasi_snapshot_preview1"."path_filestat_get": [I32, I32, I32, I32, I32] -> [I32]
"wasi_snapshot_preview1"."path_open": [I32, I32, I32, I32, I32, I64, I64, I32, I32] -> [I32]
"wasi_snapshot_preview1"."path_unlink_file": [I32, I32, I32] -> [I32]

Again, this is for my personal use-case.

Codecov Report

Merging #1116 (ddb7141) into master (ddb7141) will not change coverage.
The diff coverage is n/a.

❗ Current head ddb7141 differs from pull request most recent head 47130ee. Consider uploading reports for the commit 47130ee to get more accurate results

@@           Coverage Diff           @@
##           master    #1116   +/-   ##
=======================================
  Coverage   78.34%   78.34%           
=======================================
  Files          47       47           
  Lines        5808     5808           
=======================================
  Hits         4550     4550           
  Misses       1258     1258           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ddb7141...47130ee. Read the comment docs.

Status?

I'll have a fix for this and a bunch of other issues in the build script later this weekend (ended up rewriting the build.rs to fix a ton of bugs, took longer than expected but basically all thats left is a bit more testing).

Not sure why I didn't merge this earlier, but at this point it would just conflict.

Ow, that sounds perfect!

@thomcc looks like this is still an issue in main are you still planing on doing the other build.rs fixes and this in one go?