Update Glibc library
-
- Posts: 18
- Joined: 2017/08/17 13:46:12
Update Glibc library
Is there any way to update the Glibc library in Centos 7.5?
I have been searching with no success for this.
Thanks a lot,
Ahmed
I have been searching with no success for this.
Thanks a lot,
Ahmed
Re: Update Glibc library
It can be updated to the latest supported version with yum update like all other CentOS packages. The latest published update is glibc-2.17-222.el7.x86_64.
Is there some specific problem that you are trying to solve with this?
Is there some specific problem that you are trying to solve with this?
Re: Update Glibc library
Please do not attempt to update glibc outside of yum or using foreign, non-CentOS, packages. You will break your system to the reinstall point if you try.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
-
- Posts: 18
- Joined: 2017/08/17 13:46:12
Re: Update Glibc library
I need to update to Glibc 2.24. as I use Blender 3d modeling application and they started building their binaries using a newer version of glibc.
some people there posted a way to build from source code using dockers but I am facing some issues with that.
Is there a reason Centos is still stuck to 2.17?
Thanks a lot for your help and feedback.
I started facing this issue recently on multiple tools am using.
some people there posted a way to build from source code using dockers but I am facing some issues with that.
Is there a reason Centos is still stuck to 2.17?
Thanks a lot for your help and feedback.
I started facing this issue recently on multiple tools am using.
Re: Update Glibc library
Yes, there is. CentOS 7 uses code published by Red Hat for RHEL 7.
Does RHEL 7 have a reason?
Yes, it does. RHEL 7 attempts to be ABI compatible for its entire lifespan, 10 years.
Red Hat will not break the systems of paying customers on a whim of <foo> developers.
Building adds dependencies on the binary. That is true. It does not always mean that the source has glibc-version-based changes.Blender started building their binaries using a newer version of glibc.
If one can build from source, then one can try to build using older glibc.a way to build from source code
You can have in Docker image a different, non-CentOS glibc. Thus there should be no need to build in docker.
Virtualization and containers are a way to have the cake and eating it too.
It is true that bleeding edge does not fit into stable systems. Not without hurt.
You can stay in conservative applications or move to cutting distros.
XY problem.
You want to use Blender. You ask how to replace glibc.
That is not the right question.
The question is how to get Blender and other apps to run on CentOS.
In priority:
1. Is there a version for el7?
2. Can it be recompiled on el7?
3. Does it run in container?
4. Can you set up VM?
5. ...
If you have already ruled out 1 and 2, then next step is to ask what "issues" do you face in container?
Re: Update Glibc library
XY question:
blender.x86_64 1:2.68a-6.el7 epel
blender.x86_64 1:2.68a-6.el7 epel
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Update Glibc library
Blender site says:
* 2.68a release: 24 July, 2013
* 2.79b release: 26 March, 2018
There seems to be a slight chance that the features of the EPEL version are felt lackluster.
The obvious action would be to contact the maintainer of EPEL version.
* 2.68a release: 24 July, 2013
* 2.79b release: 26 March, 2018
There seems to be a slight chance that the features of the EPEL version are felt lackluster.
The obvious action would be to contact the maintainer of EPEL version.
-
- Posts: 18
- Joined: 2017/08/17 13:46:12
Re: Update Glibc library
Thanks, @jlehtone, and @TrevorH
I get your points for sure
there are no problems with the stable builds of blender 7.79 my problem is with daily builds of 2.8 the next version of blender.
I use a mix of proprietary software that is mainly supported on Centos and other opensource tools.
For me, a computer is just a tool to achive my work and art. So I give the priority to the tool rather than to the OS , so my first reaction to this was what another Linux is supporting GLibc 2.24 now. but I would risk running the other software I rely on, on a not supported OS. So I chose to stick to Centos.
sure a stable reliable OS is very very important. this why I switched to Linux coming from Mac Os due to lack of good hardware options. I ran windows for a while but I have always hated it.
I started doing CG in the mid 90's on Silicon Graphics machines running IRIX, and that was rock solid and I got used to having this rock solid OS. switching to windows from that, was a nightmare. I always kept an eye on Linux, but it always felt a bit too technical. I know my way around shells since the Irix times and used dos before but am no wizard. and as digital artists, we face enough technical problems with the tools we use. I didn't want to add another layer to that. until it was time to make the switch 2 years ago now. I never regrated it as I like Linux a lot.
I hope this gets sorted out sometimes soon without having to dive in a lot of technicalities that I just don't use on a daily basis or are that generally useful to my line of work as I have already too much on my plate. It would be great if Linux reaches that point when it can be just used by anyone. and it is closer to this nowadays than it was ever.
Thanks for the help, I really appreciate your time and effort.
Ahmed Barakat
I get your points for sure
there are no problems with the stable builds of blender 7.79 my problem is with daily builds of 2.8 the next version of blender.
I use a mix of proprietary software that is mainly supported on Centos and other opensource tools.
For me, a computer is just a tool to achive my work and art. So I give the priority to the tool rather than to the OS , so my first reaction to this was what another Linux is supporting GLibc 2.24 now. but I would risk running the other software I rely on, on a not supported OS. So I chose to stick to Centos.
sure a stable reliable OS is very very important. this why I switched to Linux coming from Mac Os due to lack of good hardware options. I ran windows for a while but I have always hated it.
I started doing CG in the mid 90's on Silicon Graphics machines running IRIX, and that was rock solid and I got used to having this rock solid OS. switching to windows from that, was a nightmare. I always kept an eye on Linux, but it always felt a bit too technical. I know my way around shells since the Irix times and used dos before but am no wizard. and as digital artists, we face enough technical problems with the tools we use. I didn't want to add another layer to that. until it was time to make the switch 2 years ago now. I never regrated it as I like Linux a lot.
I hope this gets sorted out sometimes soon without having to dive in a lot of technicalities that I just don't use on a daily basis or are that generally useful to my line of work as I have already too much on my plate. It would be great if Linux reaches that point when it can be just used by anyone. and it is closer to this nowadays than it was ever.
Thanks for the help, I really appreciate your time and effort.
Ahmed Barakat
-
- Posts: 17
- Joined: 2008/11/19 04:41:58
- Location: Montreal
- Contact:
Re: Update Glibc library
According to https://pkgs.org/download/glibc CentOS 7 is 11 minor versions behind Fedora.
https://www.gnu.org/software/libc/ does not even mention the version run by CentOS 7. It only goes back half a decade (2013) to mention the version that is one later than the one distributed as part of CentOS.
Stability is great. However, back in 2012, I was running a very stable CentOS 6 but RedHat (and CentOS) went ahead released newer versions.
https://cbs.centos.org/koji/packageinfo?packageID=2172 has an updated version (22) built in 2015 that has the missing library but Blender requires at least version 23 which was released 2 years ago.
It may be possible to get the Blender guys to relax their minimum to version 22 (2 years old) but it seems a bit odd to have a library that is widely used stuck at a version that is more than 5 years old.
https://www.gnu.org/software/libc/ does not even mention the version run by CentOS 7. It only goes back half a decade (2013) to mention the version that is one later than the one distributed as part of CentOS.
Stability is great. However, back in 2012, I was running a very stable CentOS 6 but RedHat (and CentOS) went ahead released newer versions.
https://cbs.centos.org/koji/packageinfo?packageID=2172 has an updated version (22) built in 2015 that has the missing library but Blender requires at least version 23 which was released 2 years ago.
It may be possible to get the Blender guys to relax their minimum to version 22 (2 years old) but it seems a bit odd to have a library that is widely used stuck at a version that is more than 5 years old.
-
- Posts: 215
- Joined: 2016/03/16 02:34:19
Re: Update Glibc library
Hey Ahmed,
Fellow CG guy here If you wish to continue using CentOS as your workstation with Blender 2.8, there’s a few choices you have.
1. Use a container system. I’m partial towards Singularity as that’s what I use daily in HPC land, but Docker is also a solution. From there you could build an Ubuntu 18.04 or even a Fedora release and run Blender through that. And yes, you can pass GPU’s through for OpenGL and rendering (speaking from experience as I’ve done it).
2. This is far more complicated, but you could build glibc 2.23+ (the version Blender specifies[0]) and do some binary ELF patching of the Blender executable. Standard LD_PRELOAD and LD_LIBRARY_PATH do not work for a library as critical as glibc.
3. Wait until CentOS 8.0 is released. I have a developer license for RHEL and I can confirm that 2.8 runs fine in RHEL 8, as it’s based off of Fedora 28/29 with glibc 2.28.
4. Build Blender from source. A few individuals have already done so and have working builds. If you have the patience, of course. A good read: https://developer.blender.org/T56837
One of the major items is the mvec.so library that Blender relies on which is completely missing in glibc 2.17.
Cheers,
Mike
[0]
Fellow CG guy here If you wish to continue using CentOS as your workstation with Blender 2.8, there’s a few choices you have.
1. Use a container system. I’m partial towards Singularity as that’s what I use daily in HPC land, but Docker is also a solution. From there you could build an Ubuntu 18.04 or even a Fedora release and run Blender through that. And yes, you can pass GPU’s through for OpenGL and rendering (speaking from experience as I’ve done it).
2. This is far more complicated, but you could build glibc 2.23+ (the version Blender specifies[0]) and do some binary ELF patching of the Blender executable. Standard LD_PRELOAD and LD_LIBRARY_PATH do not work for a library as critical as glibc.
3. Wait until CentOS 8.0 is released. I have a developer license for RHEL and I can confirm that 2.8 runs fine in RHEL 8, as it’s based off of Fedora 28/29 with glibc 2.28.
4. Build Blender from source. A few individuals have already done so and have working builds. If you have the patience, of course. A good read: https://developer.blender.org/T56837
One of the major items is the mvec.so library that Blender relies on which is completely missing in glibc 2.17.
Cheers,
Mike
[0]
Code: Select all
ldd -v blender
Version information:
./blender:
libgcc_s.so.1 (GCC_4.0.0) => /lib64/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.4) => /lib64/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.3) => /lib64/libgcc_s.so.1
libgcc_s.so.1 (GCC_4.2.0) => /lib64/libgcc_s.so.1
libmvec.so.1 (GLIBC_2.22) => not found
libm.so.6 (GLIBC_2.23) => not found
libm.so.6 (GLIBC_2.15) => /lib64/libm.so.6
libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.9) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.10) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.8) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.6) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.17) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.15) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.7) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
librt.so.1 (GLIBC_2.2.5) => /lib64/librt.so.1
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.4) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_2.12) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.3) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.2) => /lib64/libpthread.so.0
libutil.so.1 (GLIBC_2.2.5) => /lib64/libutil.so.1
/lib64/librt.so.1:
libpthread.so.0 (GLIBC_2.3.2) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_PRIVATE) => /lib64/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libpthread.so.0:
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/usr/lib64/nvidia/libGL.so.1:
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libX11.so.6:
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.15) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
/lib64/libXi.so.6:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
/lib64/libXxf86vm.so.1:
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libXfixes.so.3:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libXrender.so.1:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libutil.so.1:
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
/lib64/libm.so.6:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
/lib64/libgcc_s.so.1:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/usr/lib64/nvidia/libGLX.so.0:
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/usr/lib64/nvidia/libGLdispatch.so.0:
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libxcb.so.1:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/lib64/libXext.so.6:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
/lib64/libXau.so.6:
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
Last edited by Mike_Rochefort on 2018/12/09 19:51:19, edited 1 time in total.
Solution Architect @RedHat | RHCE
Former SysAdmin @BlueSkyStudios and @Pixar
Feature animation and VFX enthusiast
--
Report CentOS Stream 8 bugs: https://da.gd/c8s-bugs
Report CentOS Stream 9 bugs: https://da.gd/c9s-bugs
Former SysAdmin @BlueSkyStudios and @Pixar
Feature animation and VFX enthusiast
--
Report CentOS Stream 8 bugs: https://da.gd/c8s-bugs
Report CentOS Stream 9 bugs: https://da.gd/c9s-bugs