Dev:2.4/Doc/Building Blender/Linux/Chroot

提供: wiki
移動先: 案内検索

This is a basic document for setting up a chroot environment so you can build a Blender Release under Linux. As I get more time I'll try to make it more readable.

D.J. Capelis provided the help initially for me to get a chroot environment for building the 64-bit linux releases. Most of the information here is derived from that work, so kudos to him for all his help. His chroots were based on the latest stable Debian releases. I followed his practice until the 2.46 release, which required gcc 4.2 for OpenMP support. The testing Debian release does support gcc 4.2, so for that release I broke the practice.

Setting up the Chroot Itself

For now, the script below (on my Ubuntu machine) will create the chroot environment I used to build the 2.46 releases. If you're not running Ubuntu or some Debian-based distro, you'll need to do a little work at first to get the basic files needed to start the Debian setup. You need to have dchroot (or schroot) installed on your system as well in order to access the environment.

In addition to the basic chroot files, you need to add packages required for building Blender. The following should be saved into a file named /tmp/Dev-chroot-packages before starting. If your system has wget installed, you can just uncomment the line in the script to automatically grab it.


# Script to install the basic chroot; set the variables below as needed

#   set the location for the chroot 
set CHROOT='/chroot'
#   set the architecture type: i386 and amd64 have been tested
set ARCH='i386'
#   Pick your favorite mirror from
set SOURCE=''

sudo apt-get install dchroot debootstrap
sudo mkdir $CHROOT
echo "blenderenv $CHROOT" | sudo tee -a /etc/dchroot.conf
sudo debootstrap --resolve-deps --arch $ARCH etch $CHROOT $SOURCE
echo "/tmp $CHROOT/tmp none bind 0 0" |sudo tee -a /etc/fstab
echo "/dev $CHROOT/dev none bind 0 0"  |sudo tee -a /etc/fstab
echo "/home $CHROOT/home none bind 0 0"  |sudo tee -a /etc/fstab
echo "/proc $CHROOT/proc proc defaults 0 0"  |sudo tee -a /etc/fstab
sudo mount -a
# (cd /tmp ; wget
sudo chroot $CHROOT apt-get update
sudo chroot $CHROOT apt-get install locales
grep en_US $CHROOT/usr/share/i18n/SUPPORTED | sudo tee -a $CHROOT/etc/locale.gen
sudo chroot $CHROOT locale-gen
cat /tmp/Dev-chroot-packages | sudo chroot $CHROOT dpkg --set-selections
sudo chroot $CHROOT apt-get --yes dselect-upgrade
sudo cp /etc/passwd /etc/shadow /etc/group /etc/sudoers /etc/hosts $CHROOT/etc/

Once this is done, you should be able to go into the chroot environment using dchroot or schroot:


If you have more than one chroot set up,

dchroot -c blenderenv

Installing GCC 4.2

The cloth modifier was added in the 2.46 release and takes advantage of OpenMP, which requires GCC 4.2 or later. Unfortunately, Debian "Etch" (the stable release) uses GCC 4.1. Upgrading to Debian "Lenny" (the next release) fixes this but also upgrades to a later version than other distros aren't using yet. The solution in the meantime is to build our own GCC 4.2 for Etch. After this, we also need to patch one fo the OpenAL include files which breaks with GCC 4.2.

# Script to build and install GCC; set the variable below as needed

#   set the location for the chroot 
set CHROOT='/chroot'

cd /tmp
tar xjf gcc-core-4.2.3.tar.bz2
tar xjf gcc-g++-4.2.3.tar.bz2
rm gcc-core-4.2.3.tar.bz2
rm gcc-g++-4.2.3.tar.bz2
mkdir build
sudo chroot $CHROOT /bin/sh -c "cd /tmp/build && \
../gcc-4.2.3/configure --enable-shared=libgcc --disable-multilib --program-suffix=-4.2 && \
make && make install"
sudo rm -rf /tmp/build

# patch the OpenAL include file to work with GCC 4.2

sed "s/ALC\(void *)\)/\1/" $CHROOT/usr/include/AL/alc.h >/tmp/alc.h
sudo cp /tmp/alc.h $CHROOT/usr/include/AL

In theory, this will build GCC and the necessary libraries. We don't want most of the shared libraries (or at least not put where we can accidentally link to them), so the "--enable-shared=libgcc" only builds the minimal libraries. All these files will be installed in /usr/local.

Building Blender

I build blender using scons. You may feel better using make. If so, you're on your own.

We build releases which differ in whether OpenGL is statically or dynamically linked, and in which Python version is supported. Currently Python 2.4 and 2.5 are supported, so there are four builds for each platform.

For all releases, all other special libraries (like png openal, openexr, etc) are linked statically. This is a bit of a pain since the order that scons spits out the libraries is (to my perception) arbitrary and so it's hard to use linker options like -Bstatic and have them work. My workaround has been to set up by hand symbolic links to the static libraries in a separate directory and tell scons to use those.

I'll put more instructions in about this part later, but for now you can download a tarball here:

To install it, cd into the directory above blender/' and untar it. When you finish you should see something like this:

# ls
build/       install/
blender/      chroot-config.tar.bz2   staticlibs/

It would be a good idea to cd into staticlibs/ and run the script there. This will double-check that all the symbolically linked static libraries are valid.

You can now change into blender/ and type ../ VERSION=2.46-RC2. This will cause all four releases to be built and placed in ../install/.

In fact, you can do this all at once:

cd blender && dchroot -c blenderenv -d ../ VERSION=2.46-RC2

Hint: If you haven't built GCC 4.2 as shown above, you will probably have a copy of installed somewhere. This isn't good for a static build. If so, you will need to uncomment the following line at the end of and make sure there is a symbolic link for this in your staticlibs directory:

#LLIBS+=' gomp-static'

Optionally, just turn off OpenMP in (WITH_BF_OPENMP=False).