GLIBC version on error when try to build against numpy on rhel5

[davidslac]

I was having so much trouble with numpy from defaults, with the whole MKL issue, certain components wouldn't load, then I heard about conda-forge, numpy from conda-forge has been working well, except, now I am trying to build h5py from source and I am getting an error on rhel5, but not rhel6 and rhel7, it works fine on red hat 6 and 7. Im not sure yet if this is an issue with how I am building h5py, but I suspect conda-forge numpy was not build to work on rhel5? The build machine is CentOS6?

When I tried to build h5py using the conda-forge numpy, at some point, I get

ImportError: /lib64/libc.so.6: version `GLIBC_2.10' not found (required by /reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/site-packages/numpy/core/multiarray.so)

Can numpy be adjusted so that it has the dependencies needed to run on rhel5, or has the community decided rhel5 is too old to support?

Again, it might be my problem, earlier in the build I get errors like this:

+ python setup.py configure --mpi
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/reg/g/psdm/sw/conda/inst/miniconda2-dev-rhel5/envs/_build/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512

[jakirkham]

Hi @davidslac, sorry to hear you are having trouble. Yes, you have assumed correctly. conda-forge builds on CentOS 6 instead of CentOS 5 (though CentOS 7, equivalent or newer versions of RHEL, Scientific Linux and most other supported Linux versions work fine), which means that the required GLIBC verion will not be met by CentOS 5. The source for the Docker image used to do this can be found here. Also, it can be acquired by running docker pull condaforge/linux-anvil. We made this decision awhile back because of a few things. They include the EOL for CentOS 5 being March 2017, some things simply having trouble building or are not supported (e.g. Qt5, LLVM, cuDNN, and reasonably recent copies of CUDA), and the cost of a total rebuild. Given the upcoming EOL for CentOS 5, I would encourage you to upgrade sooner rather than later. I understand that this does cause difficulties for some potential users and breaks with the manylinux effort. However, it seems to be the right decision even though it comes with a cost.

That being said, you're more than welcome to use our sources to build. All of them can be acquired via the feedstocks repo, which uses git submodules to collect them together. The recipe directory inside each submodule contains the conda recipe you would need to build. conda-build also added some logic to make this easier to work with in version 1.20.2 and later. As we use devtoolset-2, it is possible to acquire this for CentOS 5 or RHEL 5. We have generally had good experiences with it as it avoids having to ship compiler libraries around.

I'm closing this a won't fix as it is a consequence of our choice of supported platform. Though please feel free to ask more questions about how to build from source.

[jakirkham]

To build numpy from source, I would like to add that you will need openblas, and the blas metapackage. For the tests of openblas, it requires perl. However, I will leave it to your discretion whether you use run the tests or not. In my experience, it takes ~25min to build openblas with tests on a single core machine and have a fair bit of knowledge doing so. If you run into issues doing so, please raise an issue on that feedstock.

[jakirkham]

I have seen hash issues like you have mentioned above in this issue ( ContinuumIO/anaconda-issues#860 ). Though it was with a different hash type. Is it possible you are using an older version of Miniconda?

[davidslac]

Thank you for all the quick feedback - sounds like a good decision to drop rhel5 support, we'd like to drop it but can't for the time being - however we should only have a limited number of users on rhel5, so we I think we can use the conda-forge numpy for most of our users. Thanks also for the link to the docker image for the build machine.

best,

David Schneider
SLAC/LCLS

---

From: jakirkham [notifications@github.com]
Sent: Thursday, July 14, 2016 5:34 PM
To: conda-forge/numpy-feedstock
Cc: Schneider, David A.; Mention
Subject: Re: [conda-forge/numpy-feedstock] GLIBC version on error when try to build against numpy on rhel5 (#20)

I have seen hash issues like you have mentioned above in this issue ( ContinuumIO/anaconda-issues#860ContinuumIO/anaconda-issues#860 ). Though it was with a different hash type. Is it possible you are using an older version of Miniconda?

�
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/20#issuecomment-232830840, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQAThQi9ynzT92e3Qp9RYcW7InsePEF5ks5qVtWvgaJpZM4JM8zn.

[msarahan]

Should you need it, there's also a CentOS 5 docker image with GCC 5.2: https://hub.docker.com/r/continuumio/conda_builder_linux/

The implication of using that GCC is that you need to list the libgcc package from defaults as a runtime dependency, or otherwise ship libstdc++ from that docker image, because it is almost certainly newer than the system libraries you have and your C++-based software may not run without it. We (conda forge and continuum) are working on a new compiler stack for Mac and Linux, but this is what we have for now. Either a DIY docker image with devtoolset-2 (the manylinux docker image would work well), or this Continuum-provided docker image.

[davidslac]

Thanks, for the time being I'm maintain separate miniconda installs for rhel5, rhel6 and rhel7, I'd like to build once with more recent technology, like a newer gcc, but keep running into issues. The last one, was building openmpi on rhel5 using, I think it was a conda package for GCC 4.8. I got a whole bunch of duplicate linker symbols - it must have been that something was still pulling in system libraries and it was colliding with the newer stdc I was trying to incorporate - anyways, build engineering - not trivial :)