'sp-version' breaks no_std builds that are not wasm

[clangenb]

The re-export of the sp_version_proc_macro::runtime_version in sp-version that was introduced here #8688. Breaks no_std builds that are not wasm.

This is inconvenient for us, as in SubstraTEE, we want to include arbitrary substrate-pallets in an sgx-enclave, which is a no-std but not wasm environment. As sp-version is a dependant of frame-system, it is virtually impossible to use any pallets without patching sp-version.

Is it an option to remove this re-export?

[bkchr]

What kind of error you get?

[clangenb]

I get some duplicate lang items error. I could identify the problematic crate to be sp-version. In this crate I found the following section, where I concluded without much more investigation that this is the issue:

substrate/primitives/version/src/lib.rs

Lines 83 to 95 in c2ec5bc

	/// # Compilation Target & "std" feature
	///
	/// This macro assumes it will be used within a runtime. By convention, a runtime crate defines a
	/// feature named "std". This feature is enabled when the runtime is compiled to native code and
	/// disabled when it is compiled to the wasm code.
	///
	/// The custom section can only be emitted while compiling to wasm. In order to detect the compilation
	/// target we use the "std" feature. This macro will emit the custom section only if the "std" feature
	/// is **not** enabled.
	///
	/// Including this macro in the context where there is no "std" feature and the code is not compiled
	/// to wasm can lead to cryptic linking errors.
	pub use sp_version_proc_macro::runtime_version;

[bkchr]

Do you use the macro? If not, it should not be responsible for what you are seeing.

[clangenb]

Ok, I could track it down. It was related to rust-lang/cargo#7915.

Adding resolver = 2 in our no_std crate prevented leakage of std from the proc_macro.

Thanks for your time! 👍