2.8 fails on Centos 7.5 #56837

New Issue

Vince Herried · 2018-09-18T20:53:01+02:00

Vince Herried commented

2018-09-18 20:53:01 +02:00

System Information
Operating system and graphics card
CentOS Linux release 7.5.1804

Blender Version
Broken: (2.80-41c039d6e90-linux-glibc224-x86_64)
Worked: (2.79b)

Short description of error
Every time I start the new version I get following error:
error while loading shared libraries: libmvec.so.1: cannot open shared object file: No such file or directory

Exact steps for others to reproduce the error
Just try to start it up.
./blender

**System Information** Operating system and graphics card CentOS Linux release 7.5.1804 **Blender Version** Broken: (2.80-41c039d6e90-linux-glibc224-x86_64) Worked: (2.79b) **Short description of error** Every time I start the new version I get following error: error while loading shared libraries: libmvec.so.1: cannot open shared object file: No such file or directory **Exact steps for others to reproduce the error** Just try to start it up. ./blender

blender-admin commented

2018-09-18 20:53:01 +02:00

#58158 was marked as duplicate of this issue

blender-admin commented

2018-09-18 20:53:01 +02:00

#59489 was marked as duplicate of this issue

Vince Herried commented

2018-09-18 20:53:02 +02:00

Added subscriber: @vince_549

Vince Herried commented

2018-09-18 21:14:13 +02:00

NVIDIA dlloader X Driver 390.67
NVIDIA GPU GeForce GTX 1050 Ti (GP107-A)

NVIDIA dlloader X Driver 390.67 NVIDIA GPU GeForce GTX 1050 Ti (GP107-A)

Ray molenkamp commented

2018-09-18 21:23:44 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-09-18 21:23:44 +02:00

your glibc is too old, buildbot recently moved to glibc224 while centos is still on 2.17

Ray molenkamp commented

2018-09-18 21:32:37 +02:00

Changed status from 'Open' to: 'Archived'

Ray molenkamp closed this issue

2018-09-18 21:32:37 +02:00

Ray molenkamp self-assigned this 2018-09-18 21:32:37 +02:00

Vince Herried commented

2018-09-18 22:37:37 +02:00

Updating Centos beyond 2.17 is very difficult if not impossible.
2.17 is the most current version available for Centos.
I thought blender was supposed to include the glibc.
EG the file name for 2.79 says blender-2.79b-linux-glibc219-x86_64/

and for 2.8
blender-2.80-41c039d6e90-linux-glibc224-x86_64.tar.bz2

Updating Centos beyond 2.17 is very difficult if not impossible. 2.17 is the most current version available for Centos. I thought blender was supposed to include the glibc. EG the file name for 2.79 says blender-2.79b-linux-glibc219-x86_64/ and for 2.8 blender-2.80-41c039d6e90-linux-glibc224-x86_64.tar.bz2

Ray molenkamp commented

2018-09-18 22:49:42 +02:00

the glib version in the filename means, build upon, (ie requires atleast) announcement email about this here

the glib version in the filename means, build upon, (ie requires atleast) announcement email about this [here ](https://lists.blender.org/pipermail/bf-committers/2018-August/049580.html)

Vince Herried commented

2018-09-18 23:05:35 +02:00

eeps. I have multiple Centos systems. This seems to mean I'm doomed to running 2.7x
Replacing Centos with say Fedora is a major effort. I used to run Fedora but it was so unstable I gave up.

eeps. I have multiple Centos systems. This seems to mean I'm doomed to running 2.7x Replacing Centos with say Fedora is a major effort. I used to run Fedora but it was so unstable I gave up.

Ray molenkamp commented

2018-09-18 23:07:43 +02:00

if you build from code centos can still work though, i fixed the last few bugs with that yesterday, instructions here

if you build from code centos can still work though, i fixed the last few bugs with that yesterday, instructions [here ](https://devtalk.blender.org/t/unable-to-run-blender-2-80-in-rhel-centos-7/2138/7)

Jeffrey Klug commented

2018-09-25 17:02:13 +02:00

Added subscriber: @JeffreyKlug

Jeffrey Klug commented

2018-09-25 17:02:13 +02:00

Many VFX and Animation studios might be stuck on RHEL or Centos 7.x due to requirements of certain commercial (closed source) applications in the pipeline. A glibc 2.17 compatible build would make Blender adoption much easier.

Ahmed Barrakat commented

2018-10-02 00:39:57 +02:00

Added subscriber: @AhmedBarakat

Ahmed Barrakat commented

2018-10-02 00:39:57 +02:00

I am stuck to Centos cause I use Substance Designer and Painter along with 3d Coat and all of these are only supported on Centos. for substance stuff on ubuntu, you can run only the steam version.
there must be a solution.

I am stuck to Centos cause I use Substance Designer and Painter along with 3d Coat and all of these are only supported on Centos. for substance stuff on ubuntu, you can run only the steam version. there must be a solution.

Ray molenkamp commented

2018-10-02 02:13:08 +02:00

blender is currently building on centos, while there are no binaries available , two users have made available a docker for building blender, available in this thread

blender is currently building on centos, while there are no binaries available , two users have made available a docker for building blender, available in [this thread ](https://devtalk.blender.org/t/unable-to-run-blender-2-80-in-rhel-centos-7/2138)

Ahmed Barrakat commented

2018-10-02 03:13:30 +02:00

@LazyDodo Thanks for pointing this. I have no experience with docker but will figure this out, is this any downside to this approach of building blender?

Brecht Van Lommel commented

2018-12-17 12:45:10 +01:00

Added subscribers: @wahn, @lichtwerk

Jan Walter commented

2018-12-18 12:12:12 +01:00

Warning: Don't do this if you don't know what you are doing !!!

FYI, if you know what you are doing and have a little hacker mindset (like me) the current Blender 2.80 can be patched to work on CentOS 7.5:

# problem: we need GLIBC_2.24
ldd /usr/local/blender-2.80/blender
- /usr/local/blender-2.80/blender: /lib64/libm.so.6: version `GLIBC_2.23' not found (required by /usr/local/blender-2.80/blender)
- for Centos 7.5
cat /etc/centos-release
- CentOS Linux release 7.5.1804 (Core) 
- where to get it from? Search for "libc.so.6(GLIBC_2.24)" on https://rpmfind.net
# check contents of RPM: rpm -qlp filename.rpm
rpm -qlp glibc-2.26-15.fc27.x86_64.rpm
# extract RPM to local folder: cd /usr/local/rpm; cp ~jan/Download/filename.rpm .; rpm2cpio filename.rpm | cpio -div
cd /usr/local/rpm
cp ~jan/Download/glibc-2.26-15.fc27.x86_64.rpm .
rpm2cpio glibc-2.26-15.fc27.x86_64.rpm | cpio -div
# use patchelf
cd /usr/local/blender-2.80-81ea815dcb6-linux-glibc224-x86_64
patchelf --set-interpreter /usr/local/rpm/lib64/ld-linux-x86-64.so.2 blender
patchelf --set-rpath /usr/local/rpm/lib64 blender

You have to be root and compile patchelf yourself ...

As a user:

# PYTHONHOME
setenv PYTHONHOME /usr/local/blender-2.80-81ea815dcb6-linux-glibc224-x86_64/2.80/python/lib/python3.7
# make sure PYTHONPATH is NOT messing things up
unsetenv PYTHONPATH
# run Blender via symbolic link
/usr/local/blender-2.80/blender

**Warning**: Don't do this if you don't know what you are doing !!! FYI, if you know what you are doing and have a little **hacker** mindset (like me) the current Blender 2.80 **can** be patched to work on **CentOS 7.5**: ``` # problem: we need GLIBC_2.24 ldd /usr/local/blender-2.80/blender - /usr/local/blender-2.80/blender: /lib64/libm.so.6: version `GLIBC_2.23' not found (required by /usr/local/blender-2.80/blender) - for Centos 7.5 cat /etc/centos-release - CentOS Linux release 7.5.1804 (Core) - where to get it from? Search for "libc.so.6(GLIBC_2.24)" on https://rpmfind.net # check contents of RPM: rpm -qlp filename.rpm rpm -qlp glibc-2.26-15.fc27.x86_64.rpm # extract RPM to local folder: cd /usr/local/rpm; cp ~jan/Download/filename.rpm .; rpm2cpio filename.rpm | cpio -div cd /usr/local/rpm cp ~jan/Download/glibc-2.26-15.fc27.x86_64.rpm . rpm2cpio glibc-2.26-15.fc27.x86_64.rpm | cpio -div # use patchelf cd /usr/local/blender-2.80-81ea815dcb6-linux-glibc224-x86_64 patchelf --set-interpreter /usr/local/rpm/lib64/ld-linux-x86-64.so.2 blender patchelf --set-rpath /usr/local/rpm/lib64 blender ``` You have to be **root** and compile [patchelf ](https://nixos.org/patchelf.html) yourself ... As a user: ``` # PYTHONHOME setenv PYTHONHOME /usr/local/blender-2.80-81ea815dcb6-linux-glibc224-x86_64/2.80/python/lib/python3.7 # make sure PYTHONPATH is NOT messing things up unsetenv PYTHONPATH # run Blender via symbolic link /usr/local/blender-2.80/blender ```

Philipp Oeser commented

2018-12-19 13:33:54 +01:00

Added subscribers: @tonemgub, @StephenSwaney, @daveb68

lirentian commented

2019-01-28 09:27:21 +01:00

Added subscriber: @lirt

lirentian commented

2019-01-28 09:27:21 +01:00

I have same issue. Can anyone help on this? Can we know when this bug will be fixed?

System Information
Operating system and graphics card
CentOS Linux release 7.2 3.10.0-327.10.1.el7.centos.plus.x86_64
graphics card: gtx 970 390.67

Blender Version
blender-2.80-690478027bd7-linux-glibc224-x86_64
Worked: (2.79b)

Short description of error
Every time I start the new version I get following error:
error while loading shared libraries: libmvec.so.1: cannot open shared object file: No such file or directory

so，I see The latest version is still not available. Please help,thanks a lot.

I have same issue. Can anyone help on this? Can we know when this bug will be fixed? System Information Operating system and graphics card CentOS Linux release 7.2 3.10.0-327.10.1.el7.centos.plus.x86_64 graphics card: gtx 970 390.67 Blender Version blender-2.80-690478027bd7-linux-glibc224-x86_64 Worked: (2.79b) Short description of error Every time I start the new version I get following error: error while loading shared libraries: libmvec.so.1: cannot open shared object file: No such file or directory so，I see The latest version is still not available. Please help,thanks a lot.

Aleksey commented

2019-05-13 14:27:01 +02:00

Added subscriber: @alekseyt

Aleksey commented

2019-05-13 14:27:01 +02:00

So, i'm not really on CentOS, but maybe someone will be looking for solution...

Everything i had to do to fix this is to download glibc 2.24 source code and do ./configure && make. Build produced mathvec/libmvec.so and math/libm.so along other binaries, i copied those two with their symlinks to directory blender/glibc/ and then did LD_LIBRARY_PATH=glibc ./blender and it just worked. I didn't use docker or whatever, also took like 5 minutes to build glibc 2.24. Maybe a more detailed description is here: https://blender.stackexchange.com/questions/120890/blender-2-8-cannot-find-libmvec-so-1

I'm on glibc 2.19 and LFS i guess, since i'm compiling glibc from sources, but Blender 2.8 from blender.org undoubtedly can work on older versions of glibc without recompilation.

Please consider linking libm and libmvec statically or providing prebuilt binaries for Linux if Blender depends on them.

It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender, but for Linux users it is recommended to change distro. But the weirdest part of all that is, of course, compiling glibc from sources to be able to start Blender 2.8.

So, i'm not really on CentOS, but maybe someone will be looking for solution... Everything i had to do to fix this is to download glibc 2.24 source code and do `./configure && make`. Build produced `mathvec/libmvec.so` and `math/libm.so` along other binaries, i copied those two with their symlinks to directory `blender/glibc/` and then did `LD_LIBRARY_PATH=glibc ./blender` and it just worked. I didn't use docker or whatever, also took like 5 minutes to build glibc 2.24. Maybe a more detailed description is here: https://blender.stackexchange.com/questions/120890/blender-2-8-cannot-find-libmvec-so-1 I'm on glibc 2.19 and LFS i guess, since i'm compiling glibc from sources, but Blender 2.8 from blender.org undoubtedly can work on older versions of glibc without recompilation. Please consider linking libm and libmvec statically or providing prebuilt binaries for Linux if Blender depends on them. It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender, but for Linux users it is recommended to change distro. But the weirdest part of all that is, of course, compiling glibc from sources to be able to start Blender 2.8.

Nuno Pereira commented

2019-05-31 12:24:37 +02:00

Added subscriber: @nunopereira

Nuno Pereira commented

2019-05-31 12:24:37 +02:00

Guys just adding to this, this situation is border-line ridiculous. CENTOS7 is the industry standard and the base support for all other VFX applications.

At UNIT we are really keen to pushing blender further into our pipeline. We work on multi-million dollar shows from feature film to commercials and TV.

You cannot go astray down a path where you leave us with no option other than ignoring blender again. Our tech teams have been at this trying to fix it, compiling and re-compiling changing our very systems and we cannot make blender work on CENTOS7. You can't expect companies to change their entire OS because you decide to compile against non standard library. I don't think you truly understand the impact of decisions like this. You are alienating the very industry that is now more keen than ever of embracing and pushing Blender further.

Aleksey is spot on on his remarks. [...]"It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender, but for Linux users it is recommended to change distro. But the weirdest part of all that is, of course, compiling glibc from sources to be able to start Blender 2.8."[...]

You need produce industry compatible builds so we can use test it, feedback uppon and have our own tech teams contributing and helping with the code base.

Thanks,

Nuno

Guys just adding to this, this situation is border-line ridiculous. CENTOS7 is the industry standard and the base support for _all_ other VFX applications. At UNIT we are really keen to pushing blender further into our pipeline. We work on multi-million dollar shows from feature film to commercials and TV. You cannot go astray down a path where you leave us with no option other than ignoring blender again. Our tech teams have been at this trying to fix it, compiling and re-compiling changing our very systems and we cannot make blender work on CENTOS7. You can't expect companies to change their entire OS because you decide to compile against non standard library. I don't think you truly understand the impact of decisions like this. You are alienating the very industry that is now more keen than ever of embracing and pushing Blender further. Aleksey is spot on on his remarks. [...]"It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender, but for Linux users it is recommended to change distro. But the weirdest part of all that is, of course, compiling glibc from sources to be able to start Blender 2.8."[...] You need produce industry compatible builds so we can use test it, feedback uppon and have our own tech teams contributing and helping with the code base. Thanks, Nuno

Jeffrey Klug commented

2019-05-31 18:37:57 +02:00

It's also worth noting (mentioned elsewhere too, I think) that the VFX Reference platform still specifies glibc 2.17 even in the current draft of CY2020. Looks like any distro that wants to remain compatible with the reference platform will be stuck with 2.17. I wish it weren't so.

Here's what I've been doing to get builds working on our CentOS 7 systems. (Can't take credit for this solution, I saw it in these forums somewhere.)

I grabbed newer libs from Fedora and copied them into /sw/lin/opt/blender/lib64

ls -l /sw/lin/opt/blender/lib64

-rwxr-xr-x+ 1 root domain users  178464 Jan 25 16:50 ld-2.26.so
lrwxrwxrwx  1 root domain users      10 Jan 25 16:50 ld-linux-x86-64.so.2 -> ld-2.26.so
-rwxr-xr-x+ 1 root domain users   19896 Jan 25 16:50 libanl-2.26.so
lrwxrwxrwx  1 root domain users      14 Jan 25 16:50 libanl.so.1 -> libanl-2.26.so
-rwxr-xr-x+ 1 root domain users    8328 Jan 25 16:50 libBrokenLocale-2.26.so
lrwxrwxrwx  1 root domain users      23 Jan 25 16:50 libBrokenLocale.so.1 -> libBrokenLocale-2.26.so
-rwxr-xr-x+ 1 root domain users 2066480 Jan 25 16:50 libc-2.26.so
-rwxr-xr-x+ 1 root domain users  197024 Jan 25 16:50 libcidn-2.26.so
lrwxrwxrwx  1 root domain users      15 Jan 25 16:50 libcidn.so.1 -> libcidn-2.26.so
lrwxrwxrwx  1 root domain users      12 Jan 25 16:50 libc.so.6 -> libc-2.26.so
-rwxr-xr-x+ 1 root domain users   19264 Jan 25 16:50 libdl-2.26.so
lrwxrwxrwx  1 root domain users      13 Jan 25 16:50 libdl.so.2 -> libdl-2.26.so
-rwxr-xr-x+ 1 root domain users 1465608 Jan 25 16:50 libm-2.26.so
lrwxrwxrwx  1 root domain users      12 Jan 25 16:50 libm.so.6 -> libm-2.26.so
-rwxr-xr-x+ 1 root domain users  180752 Jan 25 16:50 libmvec-2.26.so
lrwxrwxrwx  1 root domain users      15 Jan 25 16:50 libmvec.so.1 -> libmvec-2.26.so
-rwxr-xr-x+ 1 root domain users  109448 Jan 25 16:50 libnsl-2.26.so
lrwxrwxrwx  1 root domain users      14 Jan 25 16:50 libnsl.so.1 -> libnsl-2.26.so
-rwxr-xr-x+ 1 root domain users   38688 Jan 25 16:50 libnss_compat-2.26.so
lrwxrwxrwx  1 root domain users      21 Jan 25 16:50 libnss_compat.so.2 -> libnss_compat-2.26.so
-rwxr-xr-x+ 1 root domain users   27048 Jan 25 16:50 libnss_dns-2.26.so
lrwxrwxrwx  1 root domain users      18 Jan 25 16:50 libnss_dns.so.2 -> libnss_dns-2.26.so
-rwxr-xr-x+ 1 root domain users   57368 Jan 25 16:50 libnss_files-2.26.so
lrwxrwxrwx  1 root domain users      20 Jan 25 16:50 libnss_files.so.2 -> libnss_files-2.26.so
-rwxr-xr-x+ 1 root domain users  149360 Jan 25 16:50 libpthread-2.26.so
lrwxrwxrwx  1 root domain users      18 Jan 25 16:50 libpthread.so.0 -> libpthread-2.26.so
-rwxr-xr-x+ 1 root domain users   98168 Jan 25 16:50 libresolv-2.26.so
lrwxrwxrwx  1 root domain users      17 Jan 25 16:50 libresolv.so.2 -> libresolv-2.26.so
-rwxr-xr-x+ 1 root domain users   43736 Jan 25 16:50 librt-2.26.so
lrwxrwxrwx  1 root domain users      13 Jan 25 16:50 librt.so.1 -> librt-2.26.so
-rwxr-xr-x+ 1 root domain users   21776 Jan 25 16:50 libSegFault.so
-rwxr-xr-x+ 1 root domain users   42592 Jan 25 16:50 libthread_db-1.0.so
lrwxrwxrwx  1 root domain users      19 Jan 25 16:50 libthread_db.so.1 -> libthread_db-1.0.so
-rwxr-xr-x+ 1 root domain users   14392 Jan 25 16:50 libutil-2.26.so
lrwxrwxrwx  1 root domain users      15 Jan 25 16:50 libutil.so.1 -> libutil-2.26.so

I install blender into the network path:

tar xjf blender-2.80-b3f96da2e605-linux-glibc224-x86_64.tar.bz2 -C /sw/lin/opt/blender/

Then use patchelf to modify the binary find so that it finds the newer libs.

cd /sw/lin/opt/blender/blender-2.80-b3f96da2e605-linux-glibc224-x86_64

patchelf --set-interpreter /sw/lin/opt/blender/lib64/ld-linux-x86-64.so.2 blender
patchelf --set-rpath /sw/lin/opt/blender/lib64 blender

This is not ideal, and I'm guessing not without problems. I wouldn't feel comfortable using it in production this way, but it has been useful to get it running well enough for evaluation and testing purposes.

It's also worth noting (mentioned elsewhere too, I think) that the [VFX Reference platform ](https://vfxplatform.com/) still specifies glibc 2.17 even in the current draft of CY2020. Looks like any distro that wants to remain compatible with the reference platform will be stuck with 2.17. I wish it weren't so. Here's what I've been doing to get builds working on our CentOS 7 systems. (Can't take credit for this solution, I saw it in these forums somewhere.) I grabbed newer libs from Fedora and copied them into /sw/lin/opt/blender/lib64 ``` ls -l /sw/lin/opt/blender/lib64 -rwxr-xr-x+ 1 root domain users 178464 Jan 25 16:50 ld-2.26.so lrwxrwxrwx 1 root domain users 10 Jan 25 16:50 ld-linux-x86-64.so.2 -> ld-2.26.so -rwxr-xr-x+ 1 root domain users 19896 Jan 25 16:50 libanl-2.26.so lrwxrwxrwx 1 root domain users 14 Jan 25 16:50 libanl.so.1 -> libanl-2.26.so -rwxr-xr-x+ 1 root domain users 8328 Jan 25 16:50 libBrokenLocale-2.26.so lrwxrwxrwx 1 root domain users 23 Jan 25 16:50 libBrokenLocale.so.1 -> libBrokenLocale-2.26.so -rwxr-xr-x+ 1 root domain users 2066480 Jan 25 16:50 libc-2.26.so -rwxr-xr-x+ 1 root domain users 197024 Jan 25 16:50 libcidn-2.26.so lrwxrwxrwx 1 root domain users 15 Jan 25 16:50 libcidn.so.1 -> libcidn-2.26.so lrwxrwxrwx 1 root domain users 12 Jan 25 16:50 libc.so.6 -> libc-2.26.so -rwxr-xr-x+ 1 root domain users 19264 Jan 25 16:50 libdl-2.26.so lrwxrwxrwx 1 root domain users 13 Jan 25 16:50 libdl.so.2 -> libdl-2.26.so -rwxr-xr-x+ 1 root domain users 1465608 Jan 25 16:50 libm-2.26.so lrwxrwxrwx 1 root domain users 12 Jan 25 16:50 libm.so.6 -> libm-2.26.so -rwxr-xr-x+ 1 root domain users 180752 Jan 25 16:50 libmvec-2.26.so lrwxrwxrwx 1 root domain users 15 Jan 25 16:50 libmvec.so.1 -> libmvec-2.26.so -rwxr-xr-x+ 1 root domain users 109448 Jan 25 16:50 libnsl-2.26.so lrwxrwxrwx 1 root domain users 14 Jan 25 16:50 libnsl.so.1 -> libnsl-2.26.so -rwxr-xr-x+ 1 root domain users 38688 Jan 25 16:50 libnss_compat-2.26.so lrwxrwxrwx 1 root domain users 21 Jan 25 16:50 libnss_compat.so.2 -> libnss_compat-2.26.so -rwxr-xr-x+ 1 root domain users 27048 Jan 25 16:50 libnss_dns-2.26.so lrwxrwxrwx 1 root domain users 18 Jan 25 16:50 libnss_dns.so.2 -> libnss_dns-2.26.so -rwxr-xr-x+ 1 root domain users 57368 Jan 25 16:50 libnss_files-2.26.so lrwxrwxrwx 1 root domain users 20 Jan 25 16:50 libnss_files.so.2 -> libnss_files-2.26.so -rwxr-xr-x+ 1 root domain users 149360 Jan 25 16:50 libpthread-2.26.so lrwxrwxrwx 1 root domain users 18 Jan 25 16:50 libpthread.so.0 -> libpthread-2.26.so -rwxr-xr-x+ 1 root domain users 98168 Jan 25 16:50 libresolv-2.26.so lrwxrwxrwx 1 root domain users 17 Jan 25 16:50 libresolv.so.2 -> libresolv-2.26.so -rwxr-xr-x+ 1 root domain users 43736 Jan 25 16:50 librt-2.26.so lrwxrwxrwx 1 root domain users 13 Jan 25 16:50 librt.so.1 -> librt-2.26.so -rwxr-xr-x+ 1 root domain users 21776 Jan 25 16:50 libSegFault.so -rwxr-xr-x+ 1 root domain users 42592 Jan 25 16:50 libthread_db-1.0.so lrwxrwxrwx 1 root domain users 19 Jan 25 16:50 libthread_db.so.1 -> libthread_db-1.0.so -rwxr-xr-x+ 1 root domain users 14392 Jan 25 16:50 libutil-2.26.so lrwxrwxrwx 1 root domain users 15 Jan 25 16:50 libutil.so.1 -> libutil-2.26.so ``` I install blender into the network path: ``` tar xjf blender-2.80-b3f96da2e605-linux-glibc224-x86_64.tar.bz2 -C /sw/lin/opt/blender/ ``` Then use patchelf to modify the binary find so that it finds the newer libs. ``` cd /sw/lin/opt/blender/blender-2.80-b3f96da2e605-linux-glibc224-x86_64 patchelf --set-interpreter /sw/lin/opt/blender/lib64/ld-linux-x86-64.so.2 blender patchelf --set-rpath /sw/lin/opt/blender/lib64 blender ``` This is not ideal, and I'm guessing not without problems. I wouldn't feel comfortable using it in production this way, but it has been useful to get it running well enough for evaluation and testing purposes.

Ray molenkamp commented

2019-05-31 19:06:56 +02:00

It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender,

It's really not, it's true on windows there is no glibc, but there is the ms c runtime (which serves the same purpose as glibc), unlike glibc the mscrt allows several versions to be installed side by side which makes shipping a newer version than what the OS shipped with possible.

>It's really weird that Windows users who don't have glibc installed don't have to change OS to run Blender, It's really not, it's true on windows there is no glibc, but there is the ms c runtime (which serves the same purpose as glibc), unlike glibc the mscrt allows several versions to be installed side by side which makes shipping a newer version than what the OS shipped with possible.

Nuno Pereira commented

2019-06-03 11:15:10 +02:00

**@Jeffrey Klug (jbklug) This is great help. I'll share this with the tech team and post the results. Though my gut feeling tells me because of reliability of dozens of workstations and render farm nodes this won't fly as it implies changing quite a lot of libraries. Either way thanks a million for the help and I'll share the outcome.@LazyDodo (LazyDodo) **

That's really good info. Which makes me wonder if Blender really insists going down this path why not ship with all non-standard dependencies. Like Nuke, Maya and Houdini do with Qt for example?

Best,

Nuno

**@Jeffrey Klug (jbklug) **This is great help. I'll share this with the tech team and post the results. Though my gut feeling tells me because of reliability of dozens of workstations and render farm nodes this won't fly as it implies changing quite a lot of libraries. Either way thanks a million for the help and I'll share the outcome.**@LazyDodo (LazyDodo) ** That's really good info. Which makes me wonder if Blender really insists going down this path why not ship with all non-standard dependencies. Like Nuke, Maya and Houdini do with Qt for example? Best, Nuno

Ray molenkamp commented

2019-06-03 13:42:49 +02:00

It does we ship 30+ dependencies, the thing is for technical reasons you can't ship glibc.

Nuno Pereira commented

2019-06-03 16:05:42 +02:00

the thing is for technical reasons you can't ship glibc.

Can you elaborate?

Thanks

> the thing is for technical reasons you can't ship glibc. Can you elaborate? Thanks

Ray molenkamp commented

2019-06-03 16:18:50 +02:00

You can't statically link glibc like the other deps, because some services on linux like nss require dynamic linking to operate properly.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.8 fails on Centos 7.5 #56837