wasmi | WebAssembly interpreter

I resolved this after seeking some help in the rust forums. enter link description here. Specifically, was not able to determine what was responsible for rust std lib being linked into my executable ... was it an issue with a crate or an issue with cargo or an issue with rustc or an issue with the linker. I did not know where the problem was born, but based on similar bugs filed I figured that somehow a crate was being compiled to bring in std lib unexpected. Turns out bug enter link description here was not related even though the error message was the same. I did not have an issue with unexpected propagations form different type of dependencies (dev-dependencies and build-dependencies). I tried all these techniques to pinpoint what was bringing in std lib:

1. I tried using cargo tree to list dependencies to list all the crate dependencies:

   wasmi v0.4.3 (/home/jlb6740/github_dev/wasmi)
   ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder)
   ├── hashbrown v0.1.8 (/home/jlb6740/github_dev/hashbrown)
   │ ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
   │ └── scopeguard v0.3.3 (/home/jlb6740/github_dev/scopeguard)
   ├── libm v0.1.2
   ├── memory_units v0.3.0
   └── parity-wasm v0.31.0 (/home/jlb6740/github_dev/parity-wasm)
   └── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
   

2. I tried using cargo rustc --verbose … but at this time verbose does not indicate anything was using default features which may include using std

3. I tried using cargo metadata … this generated a long list of dependencies that was hard to parse, but I did see some instances where scopeguard and byteorder had default features requiring std support. I downloaded all of these crates and just hardcoded attributes so that the crates would only build with no_std support.

4. I tried looking at the deps/ output and did an nm on all of the rlibs to see if any of the libraries used symbols found in std. I could not find that that was the case. I thought rlibs were like static libraries and that anything they used would be included in the rlib but apparently not.

5. I looked at cargo rustc -- -C --print-link-args to check out linker flags but I could not find anything obvious telling me it was bringing in std lib.

None of these things helped me to pinpoint what was introducing std lib. Ultimately the suggestion at the rust forums was to use cargo check for a target that does not allow std lib at all. Those with a * listed here: enter link description here have only core support. I tried that, running with --target=thumbv7m-none-eabi and saw:

error[E0463]: can’t find crate for alloc
–> /home/jlb6740/github_dev/hashbrown/src/lib.rs:44:1
|
44 | extern crate std as alloc;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ can’t find crate

Turns out it was hashbrown which was a dependency of a dependency of my executable. It built no_std by default but had an extern std linked under a different name and which was guarded by a feature called “nightly”. The guard was disabled in my efforts to not build anything but no_std. Nothing I’d tried alerted me to the crate which was responsible until this. Seems there should be a better way to get a more comprehensive list of crate dependencies than what cargo tree provided, but changing the wasmi cargo to make sure the nightly feature was set solved my issue.