Undefined symbols for architecture arm64: "_rust_crypto_util_fixed_time_eq_asm" linking with `cc` failed:

Question

I am working with rust_crypto crate to sign a text and verify the signature. However, I am unable to fix the error that arises while executing this particular code snippet.

Code Snippet

#[cfg(test)]
mod test {
    use crypto::ed25519;
    use rand::RngCore;
    use rand::rngs::OsRng;
    #[test]
    fn test_signature() {
        let mut key: [u8; 32] = [0; 32];
        OsRng.fill_bytes(&mut key);

        let (secrect_key, public_key) = ed25519::keypair(&key);
        let secret_key = secrect_key.to_vec();
        let public_key = public_key.to_vec();

        let signature = ed25519::signature("test".as_bytes(), &secret_key);
        assert!(ed25519::verify(
            "test".as_bytes(),
            &public_key,
            &signature
        ));
    }
}

Error log

error: linking with `cc` failed: exit status: 1
......
Undefined symbols for architecture arm64:
"_rust_crypto_util_fixed_time_eq_asm", referenced from:
    crypto::util::fixed_time_eq::had478626f0557b6f in libcrypto-7bb502040bea4c30.rlib(crypto-7bb502040bea4c30.crypto.4149e1f8-cgu.8.rcgu.o)
ld: symbol(s) not found for architecture arm64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

Dependencies

[dependencies]
rust-crypto = "^0.2"
rand = "0.8.5"

Is this platform specific? How to solve this?

Update

As of this issue, rust-crypto is no longer maintained.

How to convert repo using rust-crypto to RustCrypto as their public, and private key structure changed.

rust-crypto

let (secrect_key, public_key) = ed25519::keypair(&key)
// `secrect_key` is `[u8;64]` and `public_key` is `[u8;32]`

RustCrypto

let signing_key = SigningKey::from_seed(&ed25519_seed).unwrap();
let verifying_key = signing_key.verifying_key();

To specifically point to the migration I am looking for:

• I previously persisted both the secrect_key & public_key in local DB (as they are just [u8]) and used them for signing, and verifying as needed.
• But, now I don't know what is the persistence strategy for signing_key, and verifying_key with this new lib.