aarch64 compiler version cannot build numpy, bug is fixed upstream

[mattip]

When building NumPy with the manylinux2014 image, I get a compiler error. How can we report issues to http://bugzilla.redhat.com/bugzilla?

The file badfile.c is a reproducer.

I don't know how to report this since it needs to be reported to redhat. Do we have a way to report issues to them?

[isuruf]

@jayfurmanek, nvm, this is an arm64 issue

[isuruf]

See conda-forge/numpy-feedstock#138 (comment) for a small testcase. @jjhelmus, do you know if this was reported?

I checked and this error is in gcc 8.2. https://godbolt.org/z/d7qkA6

[jjhelmus]

@jjhelmus, do you know if this was reported?

I reported the issue and it was fixed upstream in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075

[mattip]

I am not familiar with the redhat release cycle. This was fixed in 2019-04-30 but is still not available in the compilers used in the manylinux2014 image:

$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)

$gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)

$ which gcc
/opt/rh/devtoolset-8/root/usr/bin/gcc

[mattip]

It seems if we enable the testing stream and install devtoolset-9 compilation runs to completion. The glibc 2.17 version (used in redhat 7.7.1908, in manylinux2014) of complex math routines are inaccurate. This trips a blacklist of these functions in NumPy. Unfortunately, the replacement np.arcsinh also seems inaccurate on aarch64 with gcc (GCC) 9.1.1 20190605.

It may be more straightforward to start a branch to use a PEP 600 manylinux_2_18 image to avoid these problems, see also ppc64le problems with NumPy and pre-2.18 glibc trig functions. Do we know

• if wheel, pip support PEP 600?
• how popular glibc2.17-based systems are for other hardware like aarch64, ppc64le ?

[jayfurmanek]

• how popular glibc2.17-based systems are for other hardware like aarch64, ppc64le ?

Since glibc2.17 is in RHEL7 and in the new manylinux2014, I'd say it's where most of the user base is at the moment, unfortunately.