Blender 2.43 install

Message

System_Failure · Post by **System_Failure** » Thu Feb 22, 2007 9:16 pm

as seen in this bug there is no official ebuild for blender 2.43, but if you cp the 2.42-r1 ebuild and build it with USE="-iconv" it will compile, but then you get the message when you type to run it that it can't save files correctly and wont let you open the program any further. anyone good with ebuilds and know how to fix this? (Please no snide comments, only help please, thank you)
-SF

Rabbi Hillel · Post by **Rabbi Hillel** » Mon Feb 26, 2007 5:23 pm

System_Failure · Post by **System_Failure** » Mon Feb 26, 2007 5:34 pm

Rabbi Hillel wrote:up

LOL ty

Bluespear · Post by **Bluespear** » Mon Feb 26, 2007 9:43 pm

I'm also looking for a working ebuild

Tried the cvs one, but compilation fail because of an libiconv error and I have no time to search what's going wrong

I'm also unable to get it from blender website, seems overloaded atm.

donmartio · Post by **donmartio** » Mon Feb 26, 2007 10:53 pm

Hmmm, same problem here.

I tried it with blender-2.42a-r1 but it can't compile with use flag 'iconv'.
Strange is, that everything was alright in blender-2.42a.

On the blender download page is only a i386 version...
May 64 bit is not realy supported though i can't find any hint.

Now i tried a little bit with the sources directly.
The first stumble was a linker error which i solved with a hint from this
post:
http://www.blender.org/forum/viewtopic.php?t=9570

Then (for testing) i create a user-def.mk containing:
export NAN_YESIAMSTUPID ?= true

When compiled everthing seems to work allright. I loaded some old .blend files and saved them with 64bit_ prefix and loaded them again.

Though i can't report any problems it is may dangerous since i don't have any realy complex .blend files.

Now it is late. But if i can find some time i'll try to create a proper interrim ebuild.

Hope it helps a little bit.

Greetings
DonMartio

Xoalin · Post by **Xoalin** » Tue Feb 27, 2007 8:10 pm

Source for the following Quote: Blender Mailing List

-Ton- wrote: [Bf-committers] 64 bits Blender
<snip>
Hi,

I cannot emphasise enough that Blender is not 64 bits safe yet. Files
you write with 64 bits Blenders now might corrupt 32 bits Blender
versions. Using library referencing won't work, and not to forget the
code itself isn't 64 bits safe, meaning you most likely won't have the
possibility to reliably use up to 8 or 16 GB memory.

To warn developers/users for this situation I've added a line of code
in Blender that exits when you compile a 64 bits, with this message:

"64 bits compiles will give incorrectly saved .blend files. Do not use
it. For testing purposes please remove this line from creator.c"

This exiting is a bit unfriendly yes, but it's easy to locate this line
and remove it for your own compiles. At least people then cannot claim
they didn't know. :)

-Ton-

IF you read through the thread you will find talk of an issue relating to handling 32/64 bit data being saved in files correctly. -Ton- suggests in that post to the mailing list that it is more pervasive than just the way the files are saved, by alluding to issues with larger memory sizes being utilized correctly.

However... Should one wish to use it still... It is relatively easy to port the last ebuild to be 2.43 compliant. (gentoo-wiki, forums should have threads on custom ebuilds)

You will have to drop support for iconv (or at least I had too :P), and modify creator.c.

As for wether or not you should do that to gain the new features, perhaps the "stable" releases of the AMD64 strain are already effected. In which case your current work might not be 32 bit compatible already! Of course perhaps there are other issues lurking...

donmartio · Post by **donmartio** » Wed Feb 28, 2007 8:25 am

I cannot emphasise enough that Blender is not 64 bits safe yet. Files
you write with 64 bits Blenders now might corrupt 32 bits Blender
versions. Using library referencing won't work, and not to forget the
code itself isn't 64 bits safe, meaning you most likely won't have the
possibility to reliably use up to 8 or 16 GB memory.

Hmmm thats quite confusing... i have a 64bit system since 3 Years and i've compiled blender since then without
32 bit chroot stuff or something like that. I never had problems using blender. Maybe the reason is, that i use
the multilib USE flag.

The other confusing point is, that i compiled the previous version with iconv support and now it tells me that the
libiconv could not be found. I may have to do some investigation where this iconv stuff comes from. I don't have
libiconv installed only the virtual package... whatever that means.... may somebody can give me a light in this matter....

You will have to drop support for iconv (or at least I had too ), and modify creator.c.

As i mentioned above you don't have to modify the creator.c but create the user-def.mk with the line

Code: Select all

export NAN_YESIAMSTUPID ?= true

in it. Never change code if you don't have to...

Greetings
DonMartio

System_Failure · Post by **System_Failure** » Fri Mar 02, 2007 10:33 pm

I have the ebuild made, but I don't know exactly where to put the user-def.mk file. I'll be happy to upload my ebuild to http://bugs.gentoo.org/show_bug.cgi?id=167694 when it's stable enough to use.
-SF

System_Failure · Post by **System_Failure** » Tue Mar 06, 2007 11:09 pm

found this: http://www.blender.org/development/buil ... th-cygwin/
so I figured from that that it needed to go in ${S}/source/blender/user-def.mk but that doesn't seem to work...
little help?

donmartio · Post by **donmartio** » Wed Mar 07, 2007 12:02 am

Well... i was quite busy the last week... but i think i've figured it out.
The Problem is (and this was my mistake), that you don't need the user-def.mk because this file will only be used,
if blender is compiled with 'make'.

In the ebuild it is just compiled with scons so the handling is different.

- create the files folder in your blender overlay
- create a file called user-config.py
- insert the line

Code: Select all

CPPFLAGS += ['-DYESIAMSTUPID']

- add the following line at the end of your src_unpack function inside the ebuild

Code: Select all

cp ${FILESDIR}/user-config.py ${S}/user-config.py

After a new

Code: Select all

ebuild blender-2.43.ebuild digest

blender starts and everything seems to work fine.

The short version of this would be:
- add the following line at the end of your src_unpack function inside the ebuild

Code: Select all

echo "CPPFLAGS += ['-DYESIAMSTUPID']" > user-config.py

But i think we should be carefull and mark this as 'THIS IS JUST FOR TESTING' because nobody knows the
trouble this can raise. Maybe all opened blender files are somewhat corrupted afterwards.
So please be carefull everyone.

This is what you get:

64 bits compiles will give incorrectly saved .blend files. Do not use it.

*** If you continue to run this executable, you really are quite stupid ***

Goeland86 · Post by **Goeland86** » Wed Mar 07, 2007 3:30 am

The issue about 64 bit blender in 2.43, and that didn't appear in 2.42, is that they are trying to port the code over to support 64 bit architectures. The 32bit compiled because even though it's amd64 compiler, it will compile and run code that was designed for 32bits without any modification. Now that 64bit support is being implemented, we can actually compile an actual 64bit blender, and since it's incomplete (corruption of .blend files, improper memory use) it's best to stick to a 32bit binary for the time being. I'm sure that as soon as 64bits are working, we'll see it happen and those developper safeties will be removed.
So for now, just untar the binary blender into /opt and do a symlink. It works just fine. And as long as yafray supports 64bits, I'm happy with it. Yay for XML data exchange format

Cheers

donmartio · Post by **donmartio** » Wed Mar 07, 2007 8:39 am

Ahhh... this is some enlightment... good to know.... thanks

colinbarnette · Post by **colinbarnette** » Wed Mar 07, 2007 12:37 pm

Is there any kind of timeline someone can give out for 2.43 to be out in portage?

System_Failure · Post by **System_Failure** » Wed Mar 07, 2007 1:18 pm

colinbarnette wrote:Is there any kind of timeline someone can give out for 2.43 to be out in portage?

I uploaded the files here: http://bugs.gentoo.org/show_bug.cgi?id=167694
due to the nature of this probably the only why an ebuild will make it into the portage tree is if it uses the binaries... at least for now. I may work on this later but for now I want to test this version I compiled.
-SF

frog-o · Post by **frog-o** » Fri Mar 09, 2007 4:23 pm

I to was very disappointed when i saw there was no 64-bit blender. But it good news that blender has 32 binary for linux which work good for me except for python scripts wich i was able to git work and i detail here
http://forums.gentoo.org/viewtopic-p-39 ... ml#3950117.

The issue about 64 bit blender in 2.43, and that didn't appear in 2.42, is that they are trying to port the code over to support 64 bit architectures

Thank for the good news Goeland86
I will look froward to a 64-bit blender. I did not see this in the blender mail list thanks for enlighting me.

Gr3yFox · Post by **Gr3yFox** » Sat Mar 10, 2007 10:41 am

Goeland86 wrote:The issue about 64 bit blender in 2.43, and that didn't appear in 2.42, is that they are trying to port the code over to support 64 bit architectures. The 32bit compiled because even though it's amd64 compiler, it will compile and run code that was designed for 32bits without any modification. Now that 64bit support is being implemented, we can actually compile an actual 64bit blender, and since it's incomplete (corruption of .blend files, improper memory use) it's best to stick to a 32bit binary for the time being. I'm sure that as soon as 64bits are working, we'll see it happen and those developper safeties will be removed.
So for now, just untar the binary blender into /opt and do a symlink. It works just fine. And as long as yafray supports 64bits, I'm happy with it. Yay for XML data exchange format
Cheers

I tryed to use the 32bit binary (I use an amd64) as you suggests but I had this error message while starting ./blender:

./blenderplayer: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

After I installed emul-linux-x86-sdl blender started, but i have some problems now: i cannot see any menu (but if i click randomly i can see that they are opened even if i cannot see them).

donmartio · Post by **donmartio** » Sat Mar 10, 2007 9:02 pm

Hmmm you may take a look here:

http://forums.gentoo.org/viewtopic-t-46 ... ight-.html

Put this into your xorg.conf

Code: Select all

Option "EnablePrivateBackZ" "yes"

Greetings
DonMartio

Gr3yFox · Post by **Gr3yFox** » Sun Mar 11, 2007 12:44 pm

I'm sorry but that did not worked for me

frog-o · Post by **frog-o** » Sun Mar 11, 2007 2:36 pm

Gr3yFox wrote:

I tryed to use the 32bit binary (I use an amd64) as you suggests but I had this error message while starting ./blender:

./blenderplayer: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

After I installed emul-linux-x86-sdl blender started, but i have some problems now: i cannot see any menu (but if i click randomly i can see that they are opened even if i cannot see them).

Did you try to run blender from a terminal is so, Dose it give any error messages? Post the error messages help out alot if any. My best guess is that you need one or more ebuild for 32-bit emulation wich (i think come default it vlos.)

Also i would install an older version of blender and see if it work maybe blender don't get along with you hardware.

Gr3yFox · Post by **Gr3yFox** » Sun Mar 11, 2007 3:57 pm

I'm sorry but blender raises no errors

I already have the latest version from portage (2.42a-r1) and it works great, I just wanted to upgrade without waiting for a valid ebuild.
At this point I'll keep this version I think. I'll wait for a stable ebuild. Thanks a lot

Gentist · Post by **Gentist** » Fri Mar 16, 2007 1:17 pm

Any chance of there being a bin ebuild (blender-bin), containing the 32bit binary version, since the 64bit version isn't safe to use? I would prefer not to have to install it outside of portage.

altrent · Post by **altrent** » Mon May 14, 2007 3:28 pm

I haven't tested yet, but this looks good: http://www.blender.org/development/rele ... s-support/
Blender v2.44: "Blender now is 64 bits safe again."

AaronPPC · Post by **AaronPPC** » Mon May 14, 2007 10:10 pm

I tried to install 2.44 by copying the ebuild and bumping the version number, but no dice.

Here is where it goes terribly wrong:

Code: Select all

--snip--
Linking library ==> 'libbf_cineon.a'
source/blender/python/BPY_interface.c:34:20: error: Python.h: No such file or directory
source/blender/python/BPY_interface.c:36:49: error: compile.h: No such file or directory
source/blender/python/BPY_interface.c:37:45: error: eval.h: No such file or directory
Compiling ==> 'BPY_menus.c'
../build/linux2/makesdna /var/tmp/portage/media-gfx/blender-2.44/work/build/linux2/source/blender/makesdna/intern/dna.c
source/blender/python/BPY_menus.c:40:20: error: Python.h: No such file or directory
In file included from source/blender/python/BPY_interface.c:60:
source/blender/python/api2_2x/constant.h:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'constant_Type'
.
.
.

EDIT: I found the fix here. Append works for 64-bit archs again!