blender on 64-bit linux

Hi all,

After reading posts describing Blender on Linux as ‘better’, I decided to plunk down for high-spec (for me) Linux machine to run Blender on. The machine is up and running now on the 64-bit (AMD64/EM64) version of RHEL 3. Since there are no binaries for my platform, I pulled down the source. It won’t compile for me under scons, which seems to be the new-and-improved way to build Blender. Error messages below.

Does anyone have any experience with building Blender on 64-bit platforms? Any suggestions would be appreciated. I am very eager to get this working and may revert to 32-bit Linux just so i can start using my new kit.

Cheers for your help!

Stu

System: AMD Athlon64 3500+, 2GB DDR400, 34GB @ 10k RPMs on RAID 1

scons build log 1:
Creating new config file: config.opts
This target is for the win32 platform only 
scons: done reading SConscript files.
scons: Building targets ...
gcc -pipe -funsigned-char -O2 -Wall -W -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -DBUILD_TIME='"17:27:14"' -DBUILD_DATE='"2004-10-10"' -DBUILD_TYPE='"dynamic"' -DNAN_BUILDINFO -DBUILD_PLATFORM='"linux2"' -I/usr/include -c -o /home/stu/blender/build/linux2/source/creator/player_buildinfo.o source/creator/buildinfo.c
g++ -pipe -funsigned-char -O2 -Wall -W -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -I/home/stu/blender/build/linux2/source/gameengine/GamePlayer/ghost -Isource/gameengine/GamePlayer/ghost -Isource/gameengine/GamePlayer/ghost -Iintern/string -Iintern/ghost -Iintern/guardedalloc -Iintern/bmfont -Iintern/moto/include -Iintern/SoundSystem -Isource/gameengine/Rasterizer/RAS_OpenGLRasterizer -Isource/kernel/gen_system -Isource/kernel/gen_messaging -Isource/gameengine/Converter -Isource/blender/imbuf -Isource/gameengine/Ketsji -Isource/blender/blenlib -Isource/blender/blenkernel -Isource/blender/readblenfile -Isource/blender -Isource/blender/include -Isource/blender/makesdna -Isource/gameengine/Rasterizer -Isource/gameengine/GameLogic -Isource/gameengine/Expressions -Isource/gameengine/Network -Isource/gameengine/SceneGraph -Isource/gameengine/Physics/common -Isource/gameengine/Physics/Sumo -Isource/gameengine/Physics/Sumo/Fuzzics/include -Isource/gameengine/Network/LoopBackNetwork -Isource/gameengine/GamePlayer/common -Isource/blender/misc -Isource/blender/blenloader -I/usr/include/python2.2 -Iextern/solid -c -o /home/stu/blender/build/linux2/source/gameengine/GamePlayer/ghost/GPG_Application.o source/gameengine/GamePlayer/ghost/GPG_Application.cpp
scons: *** [/home/stu/blender/build/linux2/source/gameengine/GamePlayer/ghost/GPG_Application.o] Error 1
scons: building terminated because of errors.

I saw posts on the net that say the ‘win32 target’ message is bogus. Next, I changed config.opts so that the game engine was not built. No go, now I get:

Using config file: config.opts
This target is for the win32 platform only 
scons: done reading SConscript files.
scons: Building targets ...
gcc -pipe -funsigned-char -O2 -Wall -W -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -DBUILD_TIME='"17:34:36"' -DBUILD_DATE='"2004-10-10"' -DBUILD_TYPE='"dynamic"' -DNAN_BUILDINFO -DBUILD_PLATFORM='"linux2"' -I/usr/include -c -o /home/stu/blender/build/linux2/source/creator/dynamic_buildinfo.o source/creator/buildinfo.c
gcc -pipe -funsigned-char -O2 -Wall -W -DGAMEBLENDER=1 -DUSE_SUMO_SOLID -DNDEBUG -Iintern/guardedalloc -I/home/stu/blender/build/linux2/source/blender/blenlib -Isource/blender/blenlib -Isource/blender/blenlib -I/home/stu/blender/build/linux2/source/blender/blenkernel -Isource/blender/blenkernel -Isource/blender/blenkernel -I/home/stu/blender/build/linux2/source/blender/include -Isource/blender/include -Isource/blender/include -I/home/stu/blender/build/linux2/source/blender/blenloader -Isource/blender/blenloader -Isource/blender/blenloader -I/home/stu/blender/build/linux2/source/blender/imbuf -Isource/blender/imbuf -Isource/blender/imbuf -I/home/stu/blender/build/linux2/source/blender/renderconverter -Isource/blender/renderconverter -Isource/blender/renderconverter -I/home/stu/blender/build/linux2/source/blender/render/extern/include -Isource/blender/render/extern/include -Isource/blender/render/extern/include -I/home/stu/blender/build/linux2/source/blender/python -Isource/blender/python -Isource/blender/python -I/home/stu/blender/build/linux2/source/blender/makesdna -Isource/blender/makesdna -Isource/blender/makesdna -I/home/stu/blender/build/linux2/source/kernel/gen_messaging -Isource/kernel/gen_messaging -Isource/kernel/gen_messaging -I/home/stu/blender/build/linux2/source/kernel/gen_system -Isource/kernel/gen_system -Isource/kernel/gen_system -I/usr/include -c -o /home/stu/blender/build/linux2/source/creator/creator.o source/creator/creator.c
scons: *** [/home/stu/blender/build/linux2/source/creator/creator.o] Error 1
scons: building terminated because of errors.

Why is blender better on linux?

From what I’ve read:

  • stability
  • speed

I’m sure you can find some lively debates on this elsewhere. But I just want to get it running on my new kit! :smiley:

Stu

Windows isn’t renowned for its OpenGL integration. Unix systems use it as standard.

LOL, you have to remember even if it’s said in passing, people will get defensive about their OS (Jedi Dawn is a Windows user).

Why doesn’t normal Blender run on 64-bit Linux? I know that the 64-bit Macs can run both 64- and 32-bit apps. Do you mean you have to get 64-bit versions of all your software?

If so, I would suggest going back to 32-bit Linux until more people can afford such machines and there are more 64-bit apps around.

Hi osxrules,

Yea, I was trying to steer clear of any what “OS is best”…they can get a little…passionate. Clearly I failed. %| I am an equal opportunity kind of OS-user. :smiley:

Complete disclosure: My decision to go Linux on this machine is part “What would Blender run better on?” and part “what OS would it be fun to play with next?”

So, here I am…with a respectable 64-bit Linux box and now where to go. I downloaded the Blender 2.34 source and tried to compile against my system. My Linux programming is a bit weak, so interpreting the scons error messages has been difficult. I don’t believe there is seperate 32-bit and 64-bit source code.

Besides working though the scons issues, it should be possible to use make for the Blender build. But my knowledge of make is limited to “make builds programs”.

Again, if anyone has insight into building Blender on any platform, it would be much appreciated.

Cheers,

Stu

Not having a 64 bit beast to play with I can’t help you further but it should be possible to run 32-bit blender through 64-bit linux… that is if you are using the x86_64 version of the AMD chip. It has a x86 architechture with 64-bit extensions, and can run 32 bit and 64 bit applications under the right kernel.

Again I haven’t toyed with it, so all this info might be as reliable as quicksand… but you might want to give it a go, and run the precompiled version from the website, and also you might want to try out a testing build from the blender.org forum’s. :
Testing build from ztonzy for linux (gcc3.3 or so) w/ loads of new features that will appear in 2.35:
http://hem.bredband.net/b311031/bfbuild/blender-2.34-linux-glibc2.3.3-i386.tar.gz
Original Post:
http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=4666&start=0

Good luck
Ben

Just a note: one of the posts that sold me on “Blender can run on 64-bit linux” was on Fedora Forum: http://www.fedoraforum.org/forum/archive/index.php/t-19203.html … there are others too.

as said b4 it depends on what processor you use. intel xeon for example is quite rude with 32apps. anyway:

if you compile it yourself it should work. make sure the compiler, gcc + makeutils are costumized for you environment. I guess you can change your architecture in /etc/make.conf. basically you should ensure that you have
CFLAGS="-march=amd64". be aware; I dont really know if “amd64” is a proper flag on your system. it may be amd_64, 64, etc. tough. :slight_smile:

I use gentoo, which is very amd64 friendly :slight_smile: so you might want to read this:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=5#doc_chap5

OK. Once i get home i’ll try out the 32-bit binaries.

AMD Athlon64 3500+
2GB DDR400
34GB @ 10k RPMs on HW Mirrored RAID
nVidia Qudro FX 700

oke amd… nice choice :slight_smile: should work afaik.

Does anyone actually have an answer for the question? I’m curious too. Has anyone compiled Blender under a 64 bit setup? Running 32 bit applications under a 64 bit machine is like having a 32 bit machine. If anyone has successfully compiled Blender under a 64 bit system, please enlighten us.

OK, I tried to run both the dynamic and static (just to test; no OpenGL support) Blender binaries with no luck. :frowning: It seems to be a libGLU library/dependancy issue which I should be able to resolve with more time.

Again, any pointers would be apprciated. :smiley:

[root@waimea stu]# blender/bin/blender-2.34-linux-glibc2.2.5-i386/blender
blender/bin/blender-2.34-linux-glibc2.2.5-i386/blender: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
[root@waimea stu]# blender/bin/blender-2.34-linux-glibc2.2.5-i386-static/blender
blender/bin/blender-2.34-linux-glibc2.2.5-i386-static/blender: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
[root@waimea stu]# rpm -qa | grep libGLU
XFree86-Mesa-libGLU-4.3.0-69.EL
[root@waimea stu]# rpm -qa | grep libstdc
libstdc++-3.2.3-42
libstdc++-ssa-3.5ssa-0.20030801.48
libstdc++-3.2.3-42
libstdc++-devel-3.2.3-42
libstdc++-ssa-devel-3.5ssa-0.20030801.48
[root@waimea stu]#

That’s a good point. Unless I can compile against my system, this is all very academic. :expressionless:

Hi Ben,

I’ve tried the build you suggested and had the more dependancy issues. As said before, I’ll need a wee bit more time to sort this out. Thanks for the pointers, though.

Stu

[root@waimea blender-2.34-linux-glibc2.3.3-i386]# ./blender
./blender: error while loading shared libraries: libGLU.so.1: cannot open shared  object file: No such file or directory
[root@waimea blender-2.34-linux-glibc2.3.3-i386]# rpm -aq | grep libGLU
XFree86-Mesa-libGLU-4.3.0-69.EL
[root@waimea blender-2.34-linux-glibc2.3.3-i386]#

Stu,

Try this in a console:


$ rpm -ql XFree86-Mesa-libGLU | grep libGLU

and this:


$ whereis libGLU

The first conmmand should tell you which libGLU.so.xx.x file the rpm provides. The second should help you find out where exactly your libGLU is and what name it goes by.

You might find that it is /usr/lib/libGLU.so without the .1 at the end (or some permutation thereof, or even in a different directory)
Then to kludge it into functioning, you could do this:


As root:
# ln -n /usr/lib/libGLU.so /usr/lib/libGLU.so.1

This makes a hard link between the first and second locations. (The second location is my guess at where it would be looking for the library.)

Also if you don’t mind proprietary drivers, try installing the right ones for your card, as this should speed things up (visually) and also it might sort out your dependancy issue. (Unless you are running ATI hardware, in which case be warned that the driver set is still less than optimal. They might solve your problem though…)

Hopefully this will be one dependancy issue cleaned up… ready for the next one!

Ben

This is interesting for many a Mac user who uses 64 bit processors. In the Mac world at least, it’s now a standard, especially with G5 laptops rumoured to be in production.

Blender should ideally support multithreading and 64 bits to get the most out of todays computers. Anyone with a G5 suffers badly because it is 64 bit AND has two processors, making Blender operating much slower than what should be possible.

Hi Ben,

First of all, thanks for the help so far. It is much appreciated.

OK, I had checked for libGLU before via rpm -qa, but here is the command line stuff for libGLU as you suggest:

[root@waimea stu]# rpm -ql XFree86-Mesa-libGLU | grep libGLU
/usr/X11R6/lib64/libGLU.so.1
/usr/X11R6/lib64/libGLU.so.1.3
/usr/lib64/libGLU.so.1

…and…

[root@waimea stu]# whereis libGLU
libGLU:
[root@waimea stu]# 

This result of the ‘whereis’ seems bad to me :o and should probably be sorted out before I should start playing around with the symbolic link. How do I sort this out?

(If this OS install was not brand spanking new, it would seem reasonable that my OS was a mess.)

Regarding nVidia video drivers, they seem to have been succesfully installed. It was easy as pie. Anecdotal evidence is a) that the OpenGL screen savers work great, b) an nVidia splash screen is visible when launching xwindows. Also, from the /var/log/XFree86.0.log file:

(II) Module nvidia: vendor="NVIDIA Corporation"
        compiled for 4.0.2, module version = 1.0.6111
        Module class: XFree86 Video Driver
...
(II) NVIDIA(0): Setting mode "1280x1024"
(II) Loading extension NV-GLX
(II) NVIDIA(0): NVIDIA 3D Acceleration Architecture Initialized
(II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture

(Note: I originally had an ATI FireGL X1-128, but the linux driver support was weak and the tech support vague and unable to answer all but the simplest of questions.)

Now, some more food for though: I think I am missing something here regarding glibc versions:

[root@waimea bin]# ll
total 11816
drwxr-xr-x    4 stu      users        4096 Aug  5 17:35 blender-2.34-linux-glibc2.2.5-i386
drwxr-xr-x    4 stu      users        4096 Aug  5 17:35 blender-2.34-linux-glibc2.2.5-i386-static
-rw-------    1 stu      users     3681423 Oct 11 19:42 blender-2.34-linux-glibc2.2.5-i386-static.tar.gz
-rw-------    1 stu      users     3545550 Oct 11 19:42 blender-2.34-linux-glibc2.2.5-i386.tar.gz
drwxr-xr-x    3 root     root         4096 Oct 12 06:56 blender-2.34-linux-glibc2.3.3-i386
-rw-------    1 stu      users     4837102 Oct 12 06:54 blender-2.34-linux-glibc2.3.3-i386.tar.gz
[root@waimea bin]# rpm -qa glibc
glibc-2.3.2-95.27
glibc-2.3.2-95.27

The binaries I am attempting to run are for glibc-2.2.5 and glibc-2.3.3, but my machine has 2.3.2, Again, this seems bad. My OS: Red Hat Enterprise Linux 3 WS, kernel 2.4.21-4. Is this going to be an issue also?

Cheers,

Stu

Ben,

OK, after confering with a mate at work, I’ve created two symbolic links…with no success in running Blender.

Furthermore, the whereis libGLU still returns ‘libGLU:’ with no path.

Anybody have some ideas or Blender on 64-bit linux experiance?

Cheers

[root@waimea bin]# whereis  libGLU
libGLU:
[root@waimea bin]# whereis  libGL
libGL: /usr/lib/libGL.la /usr/lib/libGL.so
[root@waimea bin]# ll /usr/lib/libGL*
lrwxrwxrwx    1 root     root           21 Sep 26 07:12 /usr/lib/libGLcore.so.1 -> libGLcore.so.1.0.6111
-rwxr-xr-x    1 root     root      7132152 Sep 26 07:12 /usr/lib/libGLcore.so.1.0.6111
-rw-r--r--    1 root     root          653 Sep 26 07:12 /usr/lib/libGL.la
lrwxrwxrwx    1 root     root           10 Sep 26 07:12 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx    1 root     root           17 Oct  6 21:16 /usr/lib/libGL.so.1 -> libGL.so.1.0.6111
-rwxr-xr-x    1 root     root       423832 Sep 26 07:12 /usr/lib/libGL.so.1.0.6111
lrwxrwxrwx    1 root     root           22 Oct 13 16:49 /usr/lib/libGLU.so.1 -> /usr/lib64/libGLU.so.1
[root@waimea bin]# ll /usr/local/lib/libGL*
lrwxrwxrwx    1 root     root           22 Oct 13 16:51 /usr/local/lib/libGLU.so.1 -> /usr/lib64/libGLU.so.1
[root@waimea bin]#

as far as i know 64 enables memory adressing but does not calculate a 3d scene faster, until your scene is so big the app nees so much ram that 32 is not enough.

but blender should get a multi cpu support soon. it sucks it only runs on single cpu on macs ;(

claas

A 64 bit PROCESSOR should speed things up a lot. Remember, in modern games hardware which is strictly realtime 3D, they are now up to 128 bits, moving to 256 soon. The reason why PCs aren’t up to speed is because you need to rewrite all software including the operating system to utilise the extra bits. Games hardware gets new special software anyway, so it’s easier to change from 32 to 64 to 128 bits.