Skip to content

cross 0.2.4 failed to compile libz-ng-sys v1.1.8 on armv7-unknown-linux-gnueabihf #1066

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 of 11 tasks
NobodyXu opened this issue Oct 8, 2022 · 8 comments
Closed
4 of 11 tasks
Labels

Comments

@NobodyXu
Copy link

NobodyXu commented Oct 8, 2022

Checklist

Describe your issue

Running cmd

cross build --target armv7-unknown-linux-gnueabihf --profile release --no-default-features --features zlib-ng,static,rustls,trust-dns,fancy-no-backtrace,log_release_max_level_debug -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

on cargo-binstall v0.15.0 failed with error:

  /usr/lib/gcc-cross/arm-linux-gnueabihf/5/include/arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
   #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h

From CI failure.

and

  In file included from /cargo/registry/src/index.crates.io-e139d0d48fed7772/libz-ng-sys-1.1.8/src/zlib-ng/compare256.c:7:0:
  /cargo/registry/src/index.crates.io-e139d0d48fed7772/libz-ng-sys-1.1.8/src/zlib-ng/fallback_builtins.h:102:15: error: unknown type name 'uint16x8x4_t'
   static inline uint16x8x4_t vld1q_u16_x4(uint16_t *a) {

This might be related to #733 and #985
I've tried setting export RUSTFLAGS="-C link-arg=-lgcc -Clink-arg=-static-libgcc" according to https://github.com/cross-rs/cross/wiki/FAQ#undefined-reference-with-build-std but still doesn't work.

Compiling libz-ng-sys worked before #1046

What target(s) are you cross-compiling for?

armv7-unknown-linux-gnueabihf

Which operating system is the host (e.g computer cross is on) running?

  • macOS
  • Windows
  • Linux / BSD
  • other OS (specify in description)

What architecture is the host?

  • x86_64 / AMD64
  • arm32
  • arm64 (including Mac M1)

What container engine is cross using?

  • docker
  • podman
  • other container engine (specify in description)

cross version

cross 0.2.4

Example

No response

Additional information / notes

No response

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Oct 8, 2022

This isn't a cross bug: it's an issue with the library you're trying to use: ARMv7HF defaults to using VFPv3, not NEON, and refuses to compile NEON intrinsics unless you basically force it to. You'd have to add -C target-feature=+neon to RUSTFLAGS, and even then I doubt it would work. If you want an ARMv7 hard-float target that supports NEON by default, use thumbv7neon-unknown-linux-gnueabihf. FYI: your library is also asking you to use -mfloat-abi=softfp which is definitely wrong here: it would have to be -mfloat-abi=hard.

There's something wrong with the libraries you are using, not with the toolchain itself.

@Alexhuszagh
Copy link
Contributor

Let me know if this fails to compile with NEON intrinsics available, in which case, there might be a bug in the toolchain. But right now, this error definitely does not seem to be an issue in cross, especially considering our toolchain is direct from Ubuntu's repositories.

@NobodyXu
Copy link
Author

NobodyXu commented Oct 8, 2022

Running

export RUSTFLAGS="-C link-arg=-lgcc -Clink-arg=-static-libgcc -C target-feature=+neon"

cross +nightly build --target armv7-unknown-linux-gnueabihf --profile release --no-default-features --features zlib-ng,static,rustls,trust-dns,fancy-no-backtrace,log_release_max_level_debug -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

still failed with the neon error.

@Alexhuszagh
Copy link
Contributor

Alexhuszagh commented Oct 8, 2022

Interesting. I still doubt this is a toolchain error since using the C++ toolchain itself works as expected:

$ docker run -it --rm ghcr.io/cross-rs/armv7-unknown-linux-gnueabihf:0.2.4 bash
$ echo '#include <iostream>

int main() {
    std::cout << "Hello World" << std::endl;
}' >> main.cc

$ arm-linux-gnueabihf-g++  main.cc -march=armv7-a -mfpu=neon-vfpv4
$ readelf -A a.out
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

$ arm-linux-gnueabihf-g++  main.cc -march=armv7-a -mfpu=neon
$  readelf -A a.out
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

IE, it supports NEONv1, VFPv3, and VFPv4, as expected. Also, just testing it with a Rust package, this also works as expected (ensuring that these are the features enabled by default, not optional ones):

$ cross build --target armv7-unknown-linux-gnueabihf -v
$  readelf -A target/armv7-unknown-linux-gnueabihf/debug/hello2
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754

$ RUSTFLAGS="-C target-feature=+neon" cross build --target armv7-unknown-linux-gnueabihf -v
$  readelf -A target/armv7-unknown-linux-gnueabihf/debug/hello2
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754

$  cross build --target thumbv7neon-unknown-linux-gnueabihf -vv
$ readelf -A target/thumbv7neon-unknown-linux-gnueabihf/debug/hello2
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754

So basically, everything works as expected here. NEON intrinsics are not enabled by default for armv7-unknown-linux-gnueabihf, but can be enabled, while they are for thumbv7neon-unknown-linux-gnueabihf.

@NobodyXu
Copy link
Author

NobodyXu commented Oct 8, 2022

That makes me even more confused on what caused the issue here.
I will probably just disables libz-ng.

@Alexhuszagh
Copy link
Contributor

Same result as #1067, using the latest main fixes this issue.

$ cross --version
cross 0.2.4 (0fcfc0b 2022-09-29)
$ cargo +nightly --version
cargo 1.66.0-nightly (0b84a35c2 2022-10-03)
cross +nightly build --target armv7-unknown-linux-gnueabihf --profile release --no-default-features --features zlib-ng,static,rustls,trust-dns,fancy-no-backtrace,log_release_max_level_debug -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

It seems like the move to GCC 9.4.0 and glibc 2.31 (from GCC 5.4.0 and 2.23) fixes the issue.

@Emilgardis
Copy link
Member

Emilgardis commented Oct 8, 2022

to fix this @NobodyXu , you can specify what image to build with, since we've fixed the direct backwards incompability with 0.2.4 and current main regarding env vars in #1047, you could specify

[package.metadata.cross.target.armv7-unknown-linux-gnueabihf]
image = "ghcr.io/cross-rs/armv7-unknown-linux-gnueabihf@sha256:45f953c4f4945a670cc0b7f2993f1581adbc60c900028ccfebdc421eef40f84a"

this comment also applies to #1067

instead of installing cross from main, use a pinned image with 0.2.4

@NobodyXu
Copy link
Author

NobodyXu commented Oct 9, 2022

Thanks, but I would probably just wait for cross v0.3.0 since it is going to be ready soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants