Remove k256 crate from frame-support dependencies

[conr2d]

Description

This PR removes k256 crate from frame-support dependencies.

k256 is used only for converting a compressed secp256k1 public key of Substrate to an uncompressed one to derive Ethereum address. This also can be done secp256k1 crate that is already used by sp-core. This PR removes redundant dependency.

Checklist

• My PR includes a detailed description as outlined in the "Description" section above
• My PR follows the labeling requirements of this project (at minimum one label for each A, B, C and D required)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• If this PR alters any external APIs or interfaces used by Polkadot, the corresponding Polkadot PR is ready as well as the corresponding Cumulus PR (optional)

[ggwpez]

Please merge in master and format the code with nightly to get the CI green.

[gilescope]

Interestingly this annoys my machine - seems to not find the right includes when building secp256k1-sys v0.6.1. I thought I would mention it in case it's not just my machine. (if anyone has a nix-shell or flake that builds this do please throw me a link)

[conr2d]

Interestingly this annoys my machine - seems to not find the right includes when building secp256k1-sys v0.6.1. I thought I would mention it in case it's not just my machine. (if anyone has a nix-shell or flake that builds this do please throw me a link)

I reproduced this issue with AppleClang shipped with Xcode. AppleClang doesn't include wasm32 target, so build will fail with the error No available targets are compatible with triple "wasm32-unknown-unknown".

In Intel Mac, the clang command is usually replaced by the homebrew version of LLVM including wasm32 target, so this issue doesn't occur. However, in Apple Silicon (M1), the clang command still points out AppleClang.

This can be solved by setting environment variables like:

export CC=/opt/homebrew/opt/llvm/bin/clang
export CXX=/opt/homebrew/opt/llvm/bin/clang++
export AR=/opt/homebrew/opt/llvm/bin/llvm-ar

If using Intel Mac, but the error is section too large, try setting:

export AR=/usr/local/opt/llvm/bin/llvm-ar

[liamaharon]

This also broke substrate builds on my machine, setting CC, CXX and AR vars didn't work for me.

❰liamaharon❙~/grimoire/substrate(gitmaster)❱✔≻ echo $CC
/opt/homebrew/opt/llvm/bin/clang
❰liamaharon❙~/grimoire/substrate(gitmaster)❱✔≻ echo $CXX
/opt/homebrew/opt/llvm/bin/clang++
❰liamaharon❙~/grimoire/substrate(gitmaster)❱✔≻ echo $AR
/opt/homebrew/opt/llvm/bin/llvm-ar

I get a bunch of warnings like this before it eventually errors out

[conr2d]

@liamaharon Can you share the result of brew info llvm? I could build substrate with the env variables on m1 Mac Studio.

I thought that sp-core already uses secp256k1, so there should not be an error, but it seems that secp256k1 is only used on the native side (not wasm). k256 is a pure rust implementation of secp256k1, so its build does not depend on external toolchain like AppleClang, but secp256k1 is a wrapper of libsecp256k1 written in C, so requires additional build process.

I can look into the issue further, but if it hinders the development, feel free to revert the commit. I am sorry for annoying.

[gilescope]

Could we switch the native dep with https://github.com/paritytech/libsecp256k1 to get round these problems? (I see this is mentioned here: #13624 )

[liamaharon]

@conr2d brew info llvm:

I checked LDFLAGS is also set correctly.

Is anyone else running a Macbook Pro M2 Max able to confirm they're having the same issue as me?

[liamaharon]

I figured it out, it was a local config issue.

I had CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include which didn't seem to cause an issue until this commit. I removed it (CPATH is now completely unset) and it compiles fine now.

[bkchr]

Yeah let's revert it: #14499