Now I have run into the same issue: I want to upgrade the julia installation (from 1.8 to current 1.10) on our workstation in order to use some packages which need the newer julia version. The workstation is on CentOS 6.10, with glibc 2.12. I have no root rights (which is probably better for the safer).
Unfortunately I could not find any official statement of glibc requirement (even in the documentation), however above in this thread I saw 2.17, so I manually installed glibc 2.17 into my local home directory via
This did not resolve the issue, as I get the same error message as above when trying to run julia. As far as I understand I need to tell either tho whole system (by changing the LD_LIBRARY_PATH; but this is not recommended) or at least julia to use the new library. Hence I did the above mentioned
Similar to the above example, while this is less than ideal it is a fact of the research ecosystem. As an example, I know of one Linux distribution which has been end of life for 15 years which is still in production due to the software stack which is custom built for this environment. SingularityCE has no problem running that operating system and application stack on a current operating system and hardware.
I was not able to run julia on CentOS 6.7 . On contacting the sys admin, he gave me access to a new cluster (fortunately or unfortunately) which was completely updated. I still have to do, what kerim suggested.
In our case the problem is more that our application (Julia) needs newer glibc files than the system can support, hence we try to provide them additionally. I think removing those inconsistencies will just lead to the original error message that glibc 2.14 is missing.
Maybe the link about Singularity might be a good approach, but for now I realized that I can use Julia 1.9.2 which appears to be a sweet-spot in terms of usability for me. Therefore I stopped searching for a solution of the glibc linking for Julia 1.10+
c80f0f1006