Undefined symbol __rbitll on Linux ARM with 3.2.0-rc1

[oscarbenjamin]

I was testing 3.2.0-rc1 and found that it failed to build on Linux ARM in CI:
flintlib/python-flint#264

The build fails with:

2025-03-03T12:41:33.7528498Z   CC  ulong_extras/primitive_root_prime.c
2025-03-03T12:41:33.7529610Z /project/.local/src/flint-3.2.0-rc1/src/ulong_extras/revbin.c: In function ‘n_revbin’:
2025-03-03T12:41:33.7538559Z /project/.local/src/flint-3.2.0-rc1/src/ulong_extras/revbin.c:22:9: error: implicit declaration of function ‘__rbitll’ [-Werror=implicit-function-declaration]
2025-03-03T12:41:33.7539839Z    22 |     n = __rbitll(n);
2025-03-03T12:41:33.7540559Z       |         ^~~~~~~~
2025-03-03T12:41:33.7618319Z /project/.local/src/flint-3.2.0-rc1/src/ulong_extras/revbin.c: At top level:
2025-03-03T12:41:33.7625654Z cc1: note: unrecognized command-line option ‘-Wno-stringop-overread’ may have been intended to silence earlier diagnostics
2025-03-03T12:41:33.7638086Z cc1: some warnings being treated as errors
2025-03-03T12:41:33.7729840Z make: *** [build/ulong_extras/revbin.lo] Error 1

FLINT's main branch builds fine though so I guess the problem is already fixed (although I'm not sure by what).

I just want to check that the fix will make it into 3.2.0 final...

Also GitHub Actions recently added Linux ARM runners which is what I am using to test this. Are those tested in FLINT's CI?

To use the ARM runners you can just set:

runs-on: ubuntu-24.04-arm

[albinahlback]

That's weird. It should be defined according to ARM C language extension. I'll look into it before we release 3.2.0.

[albinahlback]

I've implemented the ARM runner, and will now try to check what goes wrong for 3.2.0-rc1.

[albinahlback]

Can't reproduce on 3.2.0-rc1: https://github.com/flintlib/flint/actions/runs/13676957883/job/38239499498

Is it the standard compiler you are using to build FLINT there, i.e. GCC 13.3.0? Because that compiler should support that instruction, you can check the source code for arm_acle.h.

[agriyakhetarpal]

Thanks, @albinahlback – it's coming from the fact that the ARM build here is using the ubuntu-24.04-arm runner with GCC 13.3.0, but https://github.com/flintlib/python-flint/actions/runs/13631086251/job/38098838101?pr=264 builds for the manylinux2014 platform tag using its Docker images, which conforms to an older toolchain¹ (GCC 10.2.1).

@oscarbenjamin, I think this might be the right time to bump to manylinux_2_28 as it brings GCC 14. I have to mention that it was earlier going to be the default in cibuildwheel in June 2025 (with cibuildwheel v3, most likely, see pypa/cibuildwheel#1772), but the Amazon Linux 2 team (which ships glibc 2.26) postponed their EoL date to June 2026, so it might be delayed.

python-flint requires Python >=3.11 anyway, which is fine for glibc 2.28. For greater compatibility across platforms, we can go ahead with manylinux_2_28 just for AArch64 and keep manylinux2014 for the rest, using https://cibuildwheel.pypa.io/en/stable/options/#linux-image.

Footnotes

1. Based on information provided via https://manylinuxinspector.joerick.me/#/manylinux2014/2025.02.28-1. ↩

[oscarbenjamin]

It is the standard compiler or at least I haven't attempted to change anything like that.

These are the commands used to build FLINT in the job that fails:
https://github.com/flintlib/python-flint/blob/3d2dd39b739f6f5092fd1cf513a0ebce8394e492/bin/build_dependencies_unix.sh#L281-L298
That is actually different from what is used in the job to build FLINT main that succeeds. Most likely the significant differences is

    --enable-arch=aarch64
    --disable-assembly
    --disable-avx2
    --disable-avx512

These are used to make a portable binary after flintlib/python-flint#170. See #1628 (comment).

I'll try with --host instead since I guess that is the preferred way as of FLINT 3.2.

[oscarbenjamin]

I think this might be the right time to bump to manylinux_2_28 as it brings GCC 14

Ah, thanks.

[agriyakhetarpal]

I'll try with --host instead since I guess that is the preferred way as of FLINT 3.2.

This would be useful to try, too, there is no use in breaking compatibility if we can still support glibc 2.17.

[oscarbenjamin]

I tried --host and it made no difference but bumping the manylinux version to 2.17 to use GCC 14 makes a difference. Now it fails with a different error:

2025-03-05T14:09:29.7038332Z   CC  mpn_extras/mulhigh.c
2025-03-05T14:09:29.7537454Z In file included from /project/.local/src/flint-3.2.0-rc1/src/fft_small.h:16,
2025-03-05T14:09:29.7538610Z                  from /project/.local/src/flint-3.2.0-rc1/src/mpn_extras/mul.c:41:
2025-03-05T14:09:29.7540350Z /project/.local/src/flint-3.2.0-rc1/src/machine_vectors.h: In function ‘vec2n_store_unaligned’:
2025-03-05T14:09:29.7558778Z /project/.local/src/flint-3.2.0-rc1/src/machine_vectors.h:1472:14: error: passing argument 1 of ‘vst1q_u64’ from incompatible pointer type [-Wincompatible-pointer-types]
2025-03-05T14:09:29.7560479Z  1472 |    vst1q_u64((unsigned long long *) z, a);
2025-03-05T14:09:29.7561183Z       |              ^~~~~~~~~~~~~~~~~~~~~~~~
2025-03-05T14:09:29.7562007Z       |              |
2025-03-05T14:09:29.7562355Z       |              long long unsigned int *
2025-03-05T14:09:29.7587981Z In file included from /project/.local/src/flint-3.2.0-rc1/src/machine_vectors.h:24:
2025-03-05T14:09:29.7590352Z /opt/rh/gcc-toolset-14/root/usr/lib/gcc/aarch64-redhat-linux/14/include/arm_neon.h:22181:22: note: expected ‘uint64_t *’ {aka ‘long unsigned int *’} but argument is of type ‘long long unsigned int *’
2025-03-05T14:09:29.7591864Z 22181 | vst1q_u64 (uint64_t *__a, uint64x2_t __b)
2025-03-05T14:09:29.7592655Z       |            ~~~~~~~~~~^~~
2025-03-05T14:09:29.7603994Z /project/.local/src/flint-3.2.0-rc1/src/machine_vectors.h: In function ‘vec2n_load_unaligned’:
2025-03-05T14:09:29.7605791Z /project/.local/src/flint-3.2.0-rc1/src/machine_vectors.h:1485:22: error: passing argument 1 of ‘vld1q_u64’ from incompatible pointer type [-Wincompatible-pointer-types]
2025-03-05T14:09:29.7607138Z  1485 |     return vld1q_u64((const unsigned long long *) a);
2025-03-05T14:09:29.7608470Z       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-03-05T14:09:29.7608849Z       |                      |
2025-03-05T14:09:29.7609229Z       |                      const long long unsigned int *
2025-03-05T14:09:29.7618832Z /opt/rh/gcc-toolset-14/root/usr/lib/gcc/aarch64-redhat-linux/14/include/arm_neon.h:12830:28: note: expected ‘const uint64_t *’ {aka ‘const long unsigned int *’} but argument is of type ‘const long long unsigned int *’
2025-03-05T14:09:29.7620130Z 12830 | vld1q_u64 (const uint64_t *__a)
2025-03-05T14:09:29.7620471Z       |            ~~~~~~~~~~~~~~~~^~~
2025-03-05T14:09:29.7771561Z make: *** [Makefile:637: build/mpn_extras/mul.lo] Error 1
2025-03-05T14:09:29.7772448Z make: *** Waiting for unfinished jobs....

This is tested in:
flintlib/python-flint#264

[albinahlback]

I was wrong. The rbit instruction is not necessarily available on all CPUs. I'll have to fix this.

[albinahlback]

@oscarbenjamin can you check if #2245 works for the compiler that previously failed?

[albinahlback]

@oscarbenjamin #2246 should fix the next error.

[oscarbenjamin]

can you check if #2245 works for the compiler that previously failed?

It still fails with error: implicit declaration of function ‘__rbitll’ when using GCC 10.

#2246 should fix the next error.

With gh-2246 and GCC 14 the FLINT build completes.

[albinahlback]

can you check if #2245 works for the compiler that previously failed?

It still fails with error: implicit declaration of function ‘__rbitll’ when using GCC 10.

Okay, then it was a bug in GCC (they refer to the ACLE documentation which states that the implemented check should work).

#2246 should fix the next error.

With gh-2246 and GCC 14 the FLINT build completes.

Perfect, I'll incorporate this soon.