Building 32 Bit Blender on 64 Bit Linux (Fedora Core 6)

[OompfTak]

...to sum it up: It's a pain in the butt

I realized that the Fedora supplied version of Blender (64 bit only) creates malformed .blend files. Alright, I thought, building Blender on my old 32 bit Linux installation wasn't that hard - let's simply build a 32 bit version from a current CVS snapshot!

The Fedora Core package manager supplies both 32 bit and 64 bit builds for uhh... several system libraries. Anyway, after some scons related script hacking (supplying the -m32 compiler switch), Blender was happily being compiled as a 32 bit version. That is, until the linking stage. Fedora Core doesn't supply a 32 bit version of the Python .so library. The i386 Python dev package only has a static version. More script hacking to link Blender statically against Python. Then, of course there's no i386 version of the OpenAL dev package. Okay, let's build that one as well. The library list goes on until I reach OpenEXR, which doesn't want to compile using my special "please build in 32 bit mode" ./configure script options.

I'm a wee bit frustrated right now and imagine that there are other users who feel the same. If I had known how friggin' painful 64 bit Linux business can be, I would have chosen a 32 bit installation instead.

<64 bit Linux rant mode>

Pros:
- 5% average/maybe speed-up or something?
- enables you to install an awful lot of RAM your mainboard/wallet doesn't support anyway

Cons:
- waste tons of disk space on dual library installations (64 bit and 32 bit compatibility crap)
- run into build problems using several apps
- stability issues/general weirdness with "64 bit unclean apps" (this sadly includes Blender)
- forget about those neat win32 video codec packs (unless movie players/libs are compiled as 32 bit versions; it's a vicious circle and you'll probably end up with a 32 bit only system running on a 64 bit O/S kernel)

</64 bit Linux rant mode>


I have some C/C++ coding background myself and am willing to invest some time into fixing Blender's 64 bit issues. I dimly remember Ton mentioning Blender not being "64 bit clean" and that this fix is on the todo list already. It seems to have something to do with the code which reads/writes .blend files. Or is this just the tip of the iceberg and the issue is even bigger and totally massive/non-trivial?

[LetterRip]

According to my discussion with Ton, I think he said four days of uninterrupted coding time should be enough for him to kill all the 64 bit incompatibility bugs.

Blender was 64 bit clean prior to going open source, but it hasn't been strictly maintained since going OS.

LetterRip

[OompfTak]

Sounds great. Thanks for the info, LetterRip.

Now I hope (being totally selfish here for a second) that this fixing marathon happens soon

Ahh... just the thought of typing "scons" and getting a usable binary right away...

[toastbusters]

Hey guys,

I have the 64 bit Ubuntu, and was able to compile blender under it, but the binary file that it gave me will not run. Is this a related problem? Granted, this is a cvs build, I tried to compile the rc3 release. I'm not sure if that's the cause, other than the fact that the only blender version I've been able to run is the one in Ubuntu's own repository.

Thanks

- enables you to install an awful lot of RAM your mainboard/wallet doesn't support anyway

Mine supports 12GB, but I'm still in the process of working on compatibility with my wallet.

[stiv]

I have the 64 bit Ubuntu, and was able to compile blender under it, but the binary file that it gave me will not run. Is this a related problem?

Probably not. But we will never know unless you give us a hint. One of our bpy developers is using 64bit loonix (ubuntu?) without problems, I'm told. As always, on any platform, you need the necessary dependant libs. Since blender uses open source libs, you can always compile them from source rather than rely on a package manager.

The issue with 32 vs 64, iiuc, is data corruption. Blend files are not guaranteed compatible between the two types. Because we regard this as a serious problem, 64bit builds are not endorsed - hence the #ifndef YESIAMSTUPID and accompanying comments in creator.c.

Note: there was a problem with the game engine using python 2.5 where a new flavor of size_t was introduced for 64bit systems. This may have been fixed. Or not.

[toastbusters]

One of our bpy developers is using 64bit loonix

You're not a fan of Linux I take it?

As always, on any platform, you need the necessary dependant libs.

I went to great lengths to meet this requirement, but if I'm not mistaken, would it not have compiled if I didn't have the dependent libs? Also, I can get the version to run that's provided in the Ubuntu repository, that and the fact that it did compile without errors suggests to me that this is not the issue. Again, I could be mistaken, which is why I'm here asking.

The issue with 32 vs 64, iiuc, is data corruption. Blend files are not guaranteed compatible between the two types. Because we regard this as a serious problem, 64bit builds are not endorsed - hence the #ifndef YESIAMSTUPID and accompanying comments in creator.c.

Uh, that's not good. I'm working on a collaborative project with three other people, all of them on different platforms. One has windows, one a mac, and one is using the 32bit ubuntu. If working with blender on my tower is going to create such compatibility problems, then I may not want to use it. That said, is this being worked on? From the earlier post in this thread, it sounds like it will take a great deal of work.

Finally...

Probably not. But we will never know unless you give us a hint.

What information could I provide? double clicking on the blender binary does nothing (read: fails to run but doesn't tell me why), and I'm not getting any feedback when I try to open it in a terminal window.

[edit]I just ran it in xterm and got the "yesiamstupid" message. I don't know why this didn't display in gnome-terminal, but I now know why it isn't running. That isn't really blender-related, though. Okay, so that just leaves me with the question of is this going to be fixed.

[stiv]

You're not a fan of Linux I take it?

To the contrary, I've been using it since kernel version 0.99pl13. Ah, good ol' Slackware and its humungous stack of 5 1/4 floppies.

One has windows, one a mac, and one is using the 32bit ubuntu.

Blend files are meant to be forward and backward compatible and to be portable between different platforms without regard to OS, cpu or endianess. At the moment, 64bit systems are an exception to this. Hence, the warning: Do NOT use 64bit builds for production work!

What information could I provide?

Run it from the command line using strace. Run it under the debugger. /me makes a preliminary bet on a glx problem

[toastbusters]

I've edited my previous post, but apparently after you read it. Wasn't quick enough.

Anyway, the problem was the "yesiamstupid" message, and for whatever reason it wasn't displaying this in the gnome-terminal but did when I tried in xterm.

It only takes me about three minutes or less to compile blender, which I have already done and found it to be working without any hiccups... except that blasted 64bit problem.

I can't use this at all for what I am doing, but I'm glad I know about it. I'll have to revert to a 32bit os then, which is a shame. I hope this gets addressed soon. Thanks for taking the time to answer my questions. Time to start downloading the 32bit ubuntu...

[z3r0_d]

I can't use this at all for what I am doing, but I'm glad I know about it. I'll have to revert to a 32bit os then, which is a shame. I hope this gets addressed soon. Thanks for taking the time to answer my questions. Time to start downloading the 32bit ubuntu...

or install a 32 bit chroot and run blender from there...
I rambled how to for ubuntu here:
http://blender.org/forum/viewtopic.php?t=10847

there's probably similar howtos for fedora

[OompfTak]

To be honest, at first I didn't even know that Blender had 64 bit issues. I remembered that several people were running pimped up custom 64 bit builds for that wee bit of extra speed. Others warned you not to compile 64 bit Blender builds. Also, Fedora's default package repository (a very strict and "clean" place) only offers a 64 bit version of Blender, so I thought that binary was okay.

After a while, I ran into the following interesting phenomenon: While doing random things in Blender, my X server suddenly freezes for a few seconds and then crashes on me. The X server restarts and I am greeted by the Fedora Core login screen. Nice.

I even have this little Blender file which causes X to crash after I do as little as a) load the file and b) quit Blender - works every time.

The interesting thing is, this crashy behaviour only affects 64 bit versions of Blender (created either by myself or downloaded from the Fedora repository). The 32 bit binary from blender.org works fine (no crashes), but its Python functionality is crippled, since installing both 32 bit and 64 bit Python versions on Fedora is a bit difficult. I haven't even managed to compile a 32 bit Python yet.

And yes, I blame that crash issue partly on ATI's crappy drivers (I'm running the latest version), but the fact that it only affects the 64 bit version of Blender tries to tell me something

[Lynx3d]

If it makes you feel better, i get weird redraw problems with 64bit compiles with an nvidia card, i guess there is something wrong in blender, but from compiler warnings and looking at the editscreen functions i couldn't find anything obvious yet...but my opengl knowledge converges to zero...basically it looks like an outdated buffer is showing when you move the mouse over headers/borders of the blender UI elements...if someone has an idea...

Until then, 32bit in chroot seems the best alternative, with all the crappy proprietary stuff like flashplayer and adobe reader plugin i figured it's easier to have a synaptic with 32bit repositories anyway, a couple of symlinks to libs and stuff also works outside of chroot.