wasmtime-py doesn't build with cargo test

[joshtriplett]

wasmtime-py uses pyo3's "extension-module" feature flag, which makes it not link libpython directly, so that it works in whatever python or libpython the address space already has loaded.

This seems perfectly reasonable, but as far as I can tell, that means that cargo test --package=wasmtime-py can't work, as it tries to link a binary. That link results in unresolved symbol errors for all the Python symbols.

@sunfishcode suggested filing this as an issue. cc @fitzgen and @alexcrichton.

[bjorn3]

Would this work?

#[cfg(test)]
#[link(name = "python")]
extern "C" {}

[joshtriplett]

@bjorn3 Linking Python is not quite as simple as #[link(name = "python")]; pyo3 has some logic in its build script to figure that out.

Apparently pyo3 documents this issue, and recommends disabling the extension-module feature when testing.

Unfortunately, that would break things like cargo test --all. I'm currently trying to figure out if there's some way to automatically disable extension-module when doing cargo test. @alexcrichton?

[konstin]

Afaik the only proper solution to this problem would be introducing something like rustc-bin-link-arg as bin equivalent to rustc-cdylib-link-arg introduced in rust-lang/cargo#6298, thereby solving rust-lang/cargo#5928

[alexcrichton]

This was sinced moved to https://github.com/bytecodealliance/wasmtime-py, so closing.