Android build fails due to `aarch64` in Rust

[keremnymn]

Hi,

I am trying to build my Tauri app which uses lancedb = "0.5.0" but it fails due to the following error:

error[E0433]: failed to resolve: use of undeclared crate or module `aarch64`
  --> C:\Users\-\.cargo\registry\src\index.crates.io-6f17d22bba15001f\lance-core-0.11.0\src\utils\cpu.rs:20:16
   |
20 |             if aarch64::has_neon_f16_support() {
   |                ^^^^^^^ use of undeclared crate or module `aarch64`
For more information about this error, try `rustc --explain E0433`.
error: could not compile `lance-core` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

    Error `Failed to run `cargo build`: command ["cargo", "build", "--package", "myapp", "--manifest-path", "C:\\Users\\-\\myapp\\src-tauri\\Cargo.toml", "--target", "aarch64-linux-android", "--lib"] exited with code 101
error Command failed with exit code 1.

[wjones127]

Ah this is because we have that implemented for target_os = "macos" and target_os = "linux". I guess we need an implementation for target_os = "android"?

https://github.com/lancedb/lance/blob/0e624517069fcd6587b366e6d3acdce9ae2d0e04/rust/lance-core/src/utils/cpu.rs#L66-L81

Alternatively, we have a feature flag fp16kernels in lance-linalg. Perhaps we could replicate that flag in lance-core and gate these functions behind that.

https://github.com/lancedb/lance/blob/0e624517069fcd6587b366e6d3acdce9ae2d0e04/rust/lance-linalg/Cargo.toml#L42-L45

[NickDarvey]

The same error occurs building for aarch64-pc-windows.

Regarding another conditional implementation in cpu.rs, there is a IsProcessorFeaturePresent method where you can check for PF_ARM_NEON_INSTRUCTIONS_AVAILABLE ^{1 2}. I'm not sure if that captures what we're checking for neatly, or if we need to use it in combination with something else ³.

Regarding using a feature flag, how does that work if only some processors support it for Windows, Linux, and Android? It looks like it's enabled for the Python build for x86_64-unknown-linux ⁴. (Does that mean the Python package won't work if someone runs it on an x86_64 machine without capability?)

Footnotes

1. https://github.com/dotnet/runtime/issues/74778#issuecomment-1235753493 ↩

2. https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/System/Threading/constant.PF_ARM_NEON_INSTRUCTIONS_AVAILABLE.html ↩

3. https://github.com/google/cpu_features/blob/main/include/cpuinfo_aarch64.h#L106-L107 ↩

4. https://github.com/lancedb/lance/blob/0bf765b219a0a8c440b259921a3bf3506fb89a75/.github/workflows/pypi-publish.yml#L18-L20 ↩

[NickDarvey]

Perhaps #2512 is a reasonable first step?

[wjones127]

Regarding using a feature flag, how does that work if only some processors support it for Windows, Linux, and Android?

The intention of the fp16kernels is that it will compile multiple versions of the fp16 stuff to support different CPU architectures ¹, and do dynamic dispatch at runtime ². For example, on x86_64, we have both avx512 and AVX versions of it. So as long as we have a good implementation of has_neon_f16_support or similar, the dynamic dispatch should work fine.

Footnotes

1. https://github.com/lancedb/lance/blob/0bf765b219a0a8c440b259921a3bf3506fb89a75/rust/lance-linalg/build.rs#L39-L61 ↩

2. https://github.com/lancedb/lance/blob/0bf765b219a0a8c440b259921a3bf3506fb89a75/rust/lance-linalg/src/distance/l2.rs#L132-L157 ↩

[keremnymn]

Currently my workaround for this is changing these lines to

https://github.com/lancedb/lance/blob/0e624517069fcd6587b366e6d3acdce9ae2d0e04/rust/lance-core/src/utils/cpu.rs#L18-L25

        #[cfg(target_arch = "aarch64")]
        {
            SimdSupport::None
        }

Giving up on the SimdSupport until the logic is changed or fixed

[polvallverdu]

Currently my workaround for this is changing these lines to

https://github.com/lancedb/lance/blob/0e624517069fcd6587b366e6d3acdce9ae2d0e04/rust/lance-core/src/utils/cpu.rs#L18-L25

        #[cfg(target_arch = "aarch64")]
        {
            SimdSupport::None
        }

Giving up on the SimdSupport until the logic is changed or fixed

Hey, any updates? I was having the same issue, @keremnymn fix worked.

[kotonadev]

Updates?

[wjones127]

I think this issue could use a volunteer to investigate how to change the SIMD logic to support both mainstream ARM servers and android.

We may also be able to disable these lines of code if the fp16kernels feature flag is not enabled. IIRC, this SIMD logic isn't needed for that.

I'm happy to review a PR for either solution.