Arch Linux User Repository

This package is also hosted on GitHub.

• Please report issues and patches at: https://github.com/bartoszek/AUR-blender-git
• CI Build Status: <img alt="Build Status" src="https://travis-ci.org/bartoszek/AUR-blender-git.svg?branch=travis" />

Use env vars to control build process:

• FRAGMENT="#{commit,tag,branch}=..." for making bisect build.
• CUDA_ARCH="sm_xx sm_yy" to build for a specific Cuda arch, supports multiple values.
• MAKEFLAGS="xxx" to override default make flags (check oom-killer disclaimer below)

Usage cases:

• makepkg CUDA_ARCH=sm_52
• yay -S blender-git --mflags "CUDA_ARCH=sm_52"

Optional features, defined at build time base on installed packages:

• cuda
• usd
• aur/optix
• openimagedenoise

Disclaimer:

If you want to prebuild cycles/compositor kernels, you have to install cuda beforehand. If you don't have cuda installed, PKGBUILD will silently discard cycles/compositor cuda kernel build.

Same goes with usd,optix,openimagedenoise features.

Out of memory killer.

You may use ninja-mem to prevent oom-killer when building on system with low memory to core ratio.

To activate use MAKEFLAGS+=" -m75" where 75 is the percentage upper threshold of memory usage when new build jobs is postponed.

Or simply lower the make jobs count in "MAKEFLAGS" variable, but bear in mind this will prolong your build process.

@niobium93 Can confirm. Please create an issue as requested in the pinned comment next time.

https://github.com/bartoszek/AUR-blender-git/issues/10

Is rendering on this for the last few days completely broken for anyone else or just me? Just trying to render the default cube on Cycles on CPU, nothing fancy, crashes immediately.

got some build errors when it is applying a patch

Applied patch build_files/cmake/platform/platform_unix.cmake cleanly. Applied patch source/blender/io/usd/CMakeLists.txt cleanly. Checking patch build_files/cmake/Modules/FindOpenEXR.cmake... error: while searching for: SET(_openexr_libs_ver_init "2.0")

SET(_openexr_FIND_COMPONENTS Half Iex IlmImf IlmThread Imath )

SET(_openexr_SEARCH_DIRS

error: patch failed: build_files/cmake/Modules/FindOpenEXR.cmake:34 error: build_files/cmake/Modules/FindOpenEXR.cmake: patch does not apply Checking patch source/blender/imbuf/intern/openexr/openexr_api.cpp... error: while searching for:

include <ImfChannelList.h>

include <ImfCompression.h>

include <ImfCompressionAttribute.h>

include <ImfIO.h>

include <ImfInputFile.h>

include <ImfOutputFile.h>

include <ImfPixelType.h>

include <ImfStandardAttributes.h>

error: patch failed: source/blender/imbuf/intern/openexr/openexr_api.cpp:38 error: source/blender/imbuf/intern/openexr/openexr_api.cpp: patch does not apply ==> ERROR: A failure occurred in prepare(). Aborting...

Command 'makepkg --force' failed to execute.

hi, i can't compile it because there no tbb/atomic.h.

@bartus Thanks! Following your suggestions, I was able to get blender-3.1 to build and run successfully.

@saburouta: it looks fine here, new tbb from staging works fine with blender-git (just disable embree and osd http://ix.io/3HhB as they links to old tbb)

btw. devtools providers nice script called archbuild which is symlinked as {extra, testing, staging}-x86_64-build allowing to quickly build your packages against one of extra, testing, staging repository. One thing to remember is adding path to create build container -r /tmp/build-somethig to prevent trashing your root fs.

@bartus That's a good point. I will try that. Thank you. Sorry to take staging/testing/customization noise to this board here.

@saburouta lot of blender deps links with tbb: opensubdiv, openvdb, openimagedenoise, alembic... Are all of them correctly linked against your new tbb library?

If blender won't build against your modified libtbb veriant you can build it with the Archs tbb in chroot and repackage the Archs tbb with just libtbb.so.2 as tbb2-libs to satisfy blender-git runtime dependency.

I see there's new tbb version sitting in the Archs staging repo, will test bender-git and get back to you.

@bartus That's what I mean with it not being a problem with this package. I upgraded tbb to a more recent version, and rebuilt many packages.

Blender's build system is just a little confusing to me. I feel like I have configured it to also update, but it keeps referring to '2', no matter what I set or patch.

I'm not saying this package has a problem, I was just hoping someone here would have understand how to configure Blender's dependencies.

@saburouta: can't see where's the problem here: libtbb.so.2 is provided in the current version of tbb.

I keep getting an error linking to libtbb.so.2. I believe this is because of my system, not anything wrong with Blender per se, but does anyone know how to configure Blender to build against a different version of tbb?

/aur/blender/blender-git/src/build/bin/blender: error while loading shared libraries: libtbb.so.2: cannot open shared object file: No such file or directory

I don't want to downgrade tbb if I can void it.

rm: cannot remove '.cache/pikaur/build/blender-git/pkg/blender-git/usr/blender-thumbnailer': No such file or directory ==> ERROR: A failure occurred in package(). Aborting...

Errors during installation after building

Removed this line from PKGBUILD and it installed successfully.

rm "${pkgdir}"/usr/blender-thumbnailer

The latest commit does not build here. It complains about a missing CMakeLists.txt.

@Sinasta @mahjong open{colorio,imageio, shadinglanguage}-qfix requires a rebuild against latest community\openexr if you're using rebuild-detector and doesn't get notifications about this, please contact @kuteta. I'll pop the pkgrel to trigger rebuild when I'm back. When community/blender finally gets updated to 2.93 those -qfix shananigans will be over.

Same issue as @Sinasta

getting this error when trying to compile the new version:

[225/4634] Generating node_scatter_volume.oso FAILED: intern/cycles/kernel/shaders/node_scatter_volume.oso cd /var/tmp/pamac-build-sinasta/blender-git/src/build/intern/cycles/kernel/shaders && /opt/osl/bin/oslc -q -O2 -I"/var/tmp/pamac-build-sinasta/blender-git/src/blender/intern/cycles/kernel/shaders" -I"/opt/osl/share/OSL/shaders" -o /var/tmp/pamac-build-sinasta/blender-git/src/build/intern/cycles/kernel/shaders/node_scatter_volume.oso /var/tmp/pamac-build-sinasta/blender-git/src/blender/intern/cycles/kernel/shaders/node_scatter_volume.osl /opt/osl/bin/oslc: error while loading shared libraries: libOpenEXR-3_0.so.27: cannot open shared object file: No such file or directory [226/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_split_avx2.cpp.o [227/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_split.cpp.o [228/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel.cpp.o [229/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_split_sse41.cpp.o [230/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_sse41.cpp.o [231/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_split_sse3.cpp.o [232/4634] Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_sse3.cpp.o [233/4634] Building CXX object intern/cycles/kernel/osl/CMakeFiles/cycles_kernel_osl.dir/osl_services.cpp.o ninja: build stopped: subcommand failed. ==> ERROR: A failure occurred in build(). Aborting...

and this error when trying to start Blender:

blender: error while loading shared libraries: libIex-3_0.so.27: cannot open shared object file: No such file or directory

@carlosnewmusic Use MAKEFLAGS to reduce memory assignment. This is mostly described below.

Less threads or just a specific cuda kernel solves that issue. The kernels consume around 3GB RAM each.

when compiling it leaves the system frozen using all available ram and swap

@bartus Don't know the exact reason, but PKGBUILD was stuck to some older version: pkgver=2.93.r103953.gbc851700a61 which did not yet had the extra opt paths.

Even after deletion of PKGBUILD it was recreated with that older version. Maybe some AUR helper bug (yay).

A clean build helped.

I had installed the qfix-packages manually before updating blender-git so i did not realize the old PKGBUILD.

Sorry and thanks for helping!

There are other problems and i will open an issue at github.

This package is also hosted on GitHub.

• Please report issues and patches at: https://github.com/bartoszek/AUR-blender-git
• CI Build Status: <img alt="Build Status" src="https://travis-ci.org/bartoszek/AUR-blender-git.svg?branch=travis" />

Use env vars to control build process:

• FRAGMENT="#{commit,tag,branch}=..." for making bisect build.
• CUDA_ARCH="sm_xx sm_yy" to build for a specific Cuda arch, supports multiple values.
• MAKEFLAGS="xxx" to override default make flags (check oom-killer disclaimer below)

Usage cases:

• makepkg CUDA_ARCH=sm_52
• yay -S blender-git --mflags "CUDA_ARCH=sm_52"

Optional features, defined at build time base on installed packages:

• cuda
• usd
• aur/optix
• openimagedenoise

Disclaimer:

If you want to prebuild cycles/compositor kernels, you have to install cuda beforehand. If you don't have cuda installed, PKGBUILD will silently discard cycles/compositor cuda kernel build.

Same goes with usd,optix,openimagedenoise features.

Out of memory killer.

You may use ninja-mem to prevent oom-killer when building on system with low memory to core ratio.

To activate use MAKEFLAGS+=" -m75" where 75 is the percentage upper threshold of memory usage when new build jobs is postponed.

Or simply lower the make jobs count in "MAKEFLAGS" variable, but bear in mind this will prolong your build process.

@sausix: Strange, as I explicitly popped up pkgrel for openshadinglanguage-qfix to trigger rebuild ( ಠ ʖ̯ ಠ) ###

Also weird, that cmake fails to find oiio since it has direct path to oiio provided in -DOPENIMAGEIO_ROOT_DIR=/opt/oiio switch. ###

Could you please add --trace-expand to cmake call and check blender-git-*-build.log for FindOpenImageIO.cmake lines.

##patch

Apply with git apply -v <(curl -s http://ix.io/2QiQ) in blender-git clone.

To get blender-git*-build.log build with makepkg -L

Then search for those lines blender-git*-build.log :

...
/build/blender-git/src/blender/build_files/cmake/Modules/FindOpenImageIO.cmake(42):  FIND_LIBRARY(OPENIMAGEIO_LIBRARY NAMES OpenImageIO HINTS /opt/oiio;/opt/lib/oiio PATH_SUFFIXES lib64 lib )
...
/usr/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake(480):  string(APPEND DETAILS [/opt/oiio/lib/libOpenImageIO.so] )
...

btw. If you want to post blender-git*-build.log use ix.io

Thanks for previous fixing!

openshadinglanguage-qfix was not updated/triggered somehow and still provided /usr/bin/oslc which was not working anymore because of newer libclang-cpp.so.

After forcing a reinstall of all your *-qfix packages, it seems like that blender-git does not find the libs in the new destinations below /opt.

CMake Error at CMakeLists.txt:926 (message):
  Cycles requires WITH_OPENIMAGEIO, the library may not have been found.
  Configure OIIO or disable WITH_CYCLES

@sausix: This is due to conflict between open{image,color}io witch was rebuild using different version ( openimageio<-opencolorio1 not opencolorio=2 )

Should be fixed now ( using openimageio-qfix since community/openimageio get rebuild against opencolorio=2 )

For any reason the dependency opencolorio always wants to replace any preinstalled opencolorio or opencolorio-git into opencolorio1 which results in:

-- Could NOT find OpenColorIO: Found unsuitable version "1.1.1", but required is at least "2.0.0" (found /usr/lib/libOpenColorIO.so;/usr/lib/libyaml-cpp.so;/usr/lib/libexpat.so;/usr/lib/libpystring.so)

And that removes color management completely except basic RGB.

What's the cause of this problem?

Found it. openimageio requires and pulls opencolorio1.

With openimageio-git:

/usr/bin/oslc: error while loading shared libraries: libOpenImageIO.so.2.2: cannot open shared object file: No such file or directory

I'm giving up.

"error merging blender-git: fatal: No current branch."

@sausix I would say outdated

Feel free to report ;)

@bartus But what is the status of this package? Temporary broken? Deprecated? Because it does not build anymore even without embree packages.

Thanks

@sausix: there is some patching required to build against Archs embree package. Check out blender-develop-git

Embree is now enabled by default since June 22.

https://developer.blender.org/rB99436acde8fbb7381f095922bb61455b0c8fb9a9

embree3/rtcore.h now missing. Referenced in src/blender/intern/cycles/kernel/kernel_types.h:21:12

Package embree solved some missing files but threw compile errors later. Package embree2 did not help.

./../lib/libcycles_kernel.a(kernel.cpp.o):kernel.cpp:function ccl::kernel_volume_stack_update_for_subsurface(ccl::KernelGlobals*, ccl::ShaderData*, ccl::Ray*, ccl::VolumeStack*) [clone .constprop.0]: error: undefined reference to 'rtcOccluded1'

Following errors ommitted.

openjpeg needs to be openjpeg2

@bartus: Thank you. I've asked here because that does not affect Blender's buildbot running CeontOS.

@sausix: simple bug, already poke the dev about it.

Doesn't build since some hours because of changes in blender source. Affects a few new data type conversions. https://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/6cf4861c3ac09fd65a765e8f8e3584713cc5303b

Compile output (first error only):

/home/as/.cache/yay/blender-git/src/blender/intern/cycles/render/image.cpp:153:34: error: could not convert 'ccl::ImageLoader::osl_filepath()' from
'OpenImageIO_v2_2::ustring' to 'bool'
  153 |     if (img->loader->osl_filepath()) {
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~^~
      |                                  |
      |                                  OpenImageIO_v2_2::ustring

Installation of newer OpenImageIO didn't help. Blender's BuildBot does compile. Affects two of my systems.

@bartus: thank you for all the help. will definitely test those optimisations

@bartus thanks for the heads up!

@kureta, oidn is now available in [community]/openimagedenoise repository, you should switch to it to resolve conflict with [community]/blender.

@berilac: You can turn one more optimization in makepkg.con by changing -mtune=xx and -march=xx to native in C/CXXFLAGS.

For me it's a speed up in bvh_build of ~10%.

To check how much time blender spend in bvh generation run blender in background mode $ blender bmw27_gpu.blend -b -f 0 -o /tmp.

@bratus: For me, I still get slower results from 2.8 - though they are markedly improved compared to the difference with default cube; at least they are no worse.

BMW demo:

• blender-2.79b
  • 256x256 -> 6:45.70
  • 512x512 -> 6:39.85
  • 756x756 -> 6:46.39
• blender-2.82
  • 256x256 -> 6:53.79
  • 512x512 -> 6:41.97
  • 756x756 -> 6:50.70

@berilac

BMW demo:

• blender-2.7 > 2:23
• blender-2.82 > 2:15

Looks like just a cold start in blender-2.8, with realistic test 2.8 is a bit faster.

@bartus: ok, so not just me then. I've been trying to find out more about this. Pretty strange development... shame

@berilac:

GTX970

Default cube:

• blender-2.7 > 1,44sec
• bledner-2.82 > 5,16sec

@bartus: thank you very much. You are right, it did look strange, though I had little idea why. coredumpctl gave me some quick insight. My $PATH was messed up, causing a version of oslc that I have from RenderManProServer to be used.

I would paste the new logs, but I guess they are not so relevant anymore. Problem solved, compilation successful, regardless of tweaking _cuda_capability.

Now I face a strange separate issue. Rendering the default cube takes around 10s with cycles and GPU (NVIDIA GeForce GTX 960M). It renders in around 2.4s using Blender 2.79b. Same for blender-git and blender-2.8-git. Working on gathering more information

@berilac: could you please limit compilation to single cuda compute capability (with blender-2.8-git run makepkg _cuda_capability=sm_52 to build sm_52 kernels)

This core dump looks really strange, please look inside coredumpctl to find what process exactly crashed.

Also could you build with verbose make ( add -v flag to ninja call here in blender-2.8-git)

Unable to compile blender-git (and also blender-2.8-git - slightly different errors, but feels like similar/same cause).

Looks to fail compiling cuda, or cycles (because of cuda?)

Not sure where to begin with diagnosis. I've been at this and research for a few hours now...getting nowhere.

log here: https://vim.cx/?1896d025ae773e0c#GnfEQysX9uKBt4zzauZ5NVSTAanzM88xphtXtTUt3pvf

I can't seem to figure out where the relevant information is. Even a point in the right direction would be appreciated.

@rubic: strange, as this symbol exist in libbost_locale.a

$ objdump -tC  /usr/lib/libboost_locale.a|grep manager::select|cut -f2;;
00000000000000e1 .hidden boost::locale::localization_backend_manager::select(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)

Failed to build for me, with the error:

[100%] Linking CXX executable ../../bin/blender
/usr/bin/ld: ../../lib/libbf_intern_locale.a(boost_locale_wrapper.cpp.o): in function `bl_locale_init':
boost_locale_wrapper.cpp:(.text+0x2f): undefined reference to `boost::locale::localization_backend_manager::global()'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x62): undefined reference to `boost::locale::localization_backend_manager::select(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x83): undefined reference to `boost::locale::localization_backend_manager::global(boost::locale::localization_backend_manager const&)'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x8c): undefined reference to `boost::locale::localization_backend_manager::~localization_backend_manager()'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0xdf): undefined reference to `boost::locale::localization_backend_manager::~localization_backend_manager()'
/usr/bin/ld: ../../lib/libbf_intern_locale.a(boost_locale_wrapper.cpp.o): in function `bl_locale_set':
boost_locale_wrapper.cpp:(.text+0x196): undefined reference to `boost::locale::generator::generator()'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x1af): undefined reference to `boost::locale::generator::add_messages_path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x1bf): undefined reference to `boost::locale::generator::add_messages_domain(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x211): undefined reference to `boost::locale::generator::generate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x27c): undefined reference to `boost::locale::base_message_format<char>::id'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x4cd): undefined reference to `boost::locale::generator::~generator()'
/usr/bin/ld: boost_locale_wrapper.cpp:(.text+0x69e): undefined reference to `boost::locale::generator::generate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
/usr/bin/ld: ../../lib/libbf_intern_locale.a(boost_locale_wrapper.cpp.o): in function `bl_locale_init.cold':
boost_locale_wrapper.cpp:(.text.unlikely+0x15): undefined reference to `boost::locale::localization_backend_manager::~localization_backend_manager()'
/usr/bin/ld: ../../lib/libbf_intern_locale.a(boost_locale_wrapper.cpp.o): in function `bl_locale_set.cold':
boost_locale_wrapper.cpp:(.text.unlikely+0xc8): undefined reference to `boost::locale::generator::~generator()'
/usr/bin/ld: ../../lib/libbf_intern_locale.a(boost_locale_wrapper.cpp.o): in function `boost::locale::info const& std::use_facet<boost::locale::info>(std::locale const&)':
boost_locale_wrapper.cpp:(.text._ZSt9use_facetIN5boost6locale4infoEERKT_RKSt6locale[_ZSt9use_facetIN5boost6locale4infoEERKT_RKSt6locale]+0x7): undefined reference to `boost::locale::info::id'
collect2: error: ld returned 1 exit status
make[2]: *** [source/creator/CMakeFiles/blender.dir/build.make:441: bin/blender] Error 1
make[1]: *** [CMakeFiles/Makefile2:7314: source/creator/CMakeFiles/blender.dir/all] Error 2

@bartus are you on freenode irc or something? I would like to talk to you about your PKGBUILD and i don't want to clutter this comment section.

@bartus so are you saying if I remove optix after installing blender, Cycles OptiX device should continue to work without problems? Also isn't this package and yours are practically same? Should we merge them?

@kureta Shouldn't Optix go in to makedepends. Optix v7.0 is header only ( symbols are pulled from the drivers)

@bartus I've already modified PKGBUILD, compiled, installed, and tested optix rendering on an RTX graphics card. Everything works fine.

Hi! I have modified your PKGBUILD file a bit. Specifically:

• removed cmake flags that are no longer applicable

    -DWITH_GAMEENGINE=ON \
    -DWITH_PLAYER=ON \

• Added optional dependencies for OptiX and Open Image Denoise Support

    optdepends=('cuda: CUDA support in Cycles'
                'optix: OptiX support in Cycles'
                'oidn: Intel Open Image Denoise support in compositing')

• Added logic for detection of these optional dependencies

    # check for optix
    _OPTIX_PKG=`pacman -Qq optix 2>/dev/null` || true
    if [ "$_OPTIX_PKG" != "" ]; then
        _EXTRAOPTS="$_EXTRAOPTS \
                    -DWITH_CYCLES_DEVICE_OPTIX=ON \
                    -DOPTIX_ROOT_DIR=/opt/optix"
    fi

    # check for open image denoise
    _OIDN_PKG=`pacman -Qq oidn 2>/dev/null` || true
    if [ "$_OIDN_PKG" != "" ]; then
        _EXTRAOPTS="$_EXTRAOPTS \
                    -DWITH_OPENIMAGEDENOISE=ON"
    fi

Maybe you can incorporate these changes into your PKGBUILD too.

@fbrennan: Consider updating pkgver scheme to preserve consistency across different blender packages in AUR.

pkgver() { cd "$srcdir/blender" printf "2.81.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" }

This would make repology versions report more usable

thanks ;)

Thanks guys, I'm working on getting it to build myself with the new changes. A state of flux is an understatement, the new development branch differs significantly from the old one so please allow time for things to stabilize :-)

This is now no longer the blender-2.79 branch. Recently blender dves have moved the blender-2.8 code into master (this PKGBUILD compiles from master) and the PKGBUILD and build options haven't been updated yet.

Things are currently in a state of flux so it may take a while to get things worked out.

I got this to build by adding the following changes to the PKGBUILD:

diff --git a/PKGBUILD b/PKGBUILD
index [`e828e21`](https://aur.archlinux.org/cgit/aur.git/commit/?h=blender-git&id=e828e21)..8fd245c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -8,7 +8,7 @@ arch=('i686' 'x86_64')
 url="<http://blender.org/>"
 depends=('libgl' 'python' 'desktop-file-utils' 'hicolor-icon-theme'
          'ffmpeg' 'fftw' 'openal' 'freetype2' 'libxi' 'openimageio' 'opencolorio'
-         'openshadinglanguage' 'libtiff' 'libpng')
+         'openshadinglanguage' 'libtiff' 'libpng' 'python-numpy')
 optdepends=('cuda: CUDA support in Cycles')
 makedepends=('git' 'cmake' 'boost' 'mesa')
 provides=('blender')
@@ -65,6 +65,7 @@ build() {
         -DWITH_PYTHON_INSTALL=OFF \
         -DPYTHON_VERSION=3.7m \
         -DWITH_MOD_OCEANSIM=ON \
+        -DPYTHON_NUMPY_PATH=/usr/lib/python3.7/site-packages \
         $_EXTRAOPTS
   make
 }

Note I'm not sure if python-numpy should be depends or make-depends, so I added it as depends in the diff.

Can´t build:

[ 93%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WXEdgeBuilder.cpp.o [ 93%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WingedEdgeBuilder.cpp.o [ 93%] Linking CXX static library ../../../lib/libbf_freestyle.a [ 93%] Built target bf_freestyle make: *** [Makefile:163: all] Error 2

@fbrennan fair point, just gotten used to installing blender-2.8-git and blender-git.

@mowcat I don't understand your point. This package is for building master just by its name. Feel free to make blender2.7-git if you want.

I needed to edit the PKGBUILD file in order to use the blender2.7 branch.

I just disowned the package. I no longer have the time to play with blender, so I believe it's time to pass it to someone else.

Python is 3.7 now. -DPYTHON_VERSION=3.7m

When I build this, the resulting package is missing the *.oso files under /usr/share/blender/2.79/scripts/addons/cycles/shader/ that the non-git package has.

I tried replacing the build function with the one from the non-git package, which uses the cmake file under build_files/cmake/config/blender_release.cmake, but then I get random compiler failures when building.

Anybody and idea how to fix this?

Appear to have solved the issue. Should anyone run into it themselves:

Edit the PKGBUILD in the build() section, in the cmake command add the following, or a variant of

-DCYCLES_CUDA_BINARIES_ARCH:STRING="sm_20;sm_21;sm_30;sm_35;sm_37;sm_50;sm_52;sm_60;sm_61"

I had to remove sm_20 and 21 before it would compile for me.

I believe I ran into something similar to the following error before. I can't remember how I eventually got around it...

[ 17%] Generating kernel_sm_20.cubin nvcc fatal : Value 'sm_20' is not defined for option 'gpu-architecture' make[2]: [intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/build.make:255: intern/cycles/kernel/kernel_sm_20.cubin] Error 1 make[1]: [CMakeFiles/Makefile2:1465: intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all] Error 2

Any ideas? googling thus far has not been very much use. Perhaps it involves a CMAKE flag for makepkg, but I am uncertain...

Somewhat tangential to this package as it doesn't enable it but... If you want openvdb with blender-git you need either to revert https://developer.blender.org/rB0d4e519b748c and use the lines from the blender package in community export CFLAGS="${CFLAGS} -DOPENVDB_3_ABI_COMPATIBLE" export CXXFLAGS="${CXXFLAGS} -DOPENVDB_3_ABI_COMPATIBLE" Or Recompile openvdb. The commits comments say you need openvdb with the below compile option -DOPENVDB_ENABLE_3_ABI_COMPATIBLE=OFF I did the recompile option which appears to work, haven't tested the revert option the above is just a guess at what is needed. Hopefully of use to someone.

@habys if you want JACK and SDL add: -DWITH_JACK=ON \ -DWITH_SDL=ON \ into 'cmake' in PKGBBUILD.

Sorry, I meant SDL, rather than ALSA

Anyone only getting OpenAL for audio? Ideally there would also be JACK and ALSA

PKBUILD needs updating change -DPYTHON_VERSION=3.5m \ to -DPYTHON_VERSION=3.6m \

Good catch!

Although the package name is blender-git, the name set by blender.desktop is blender-svn. Can you change this?

Thanks guys! It should compile now.

Latest blender build requires OSL 1.73. Arch provides OSL 1.72 witch breaks build while linking final binary.

New build requires 'blender-dev-tools.git'. --- https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/3ba83e247a80d8c8c8fe5fb4f1d32b5c2694b53c > Add developer tools submodule > > This is intended for utilities to help with development, which aren't needed for building.

Roken, I get a build error too, when it tries to build the CUDA kernels. Something about a 'nullprt' being undefined. I have not done any research into this though. If I have the time and find anything, I'll report back.

I'm guessing the problem is gcc 6.1.1. Apparently there's a patch, which hasn't made it to git yet.

I can't build, error at 96% CMakeFiles/Makefile2:1293: recipe for target 'intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all' failed make[1]: *** [intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all] Error 2 Any ideas?

Thanks stativ, you were right! Turned out I ran out of disk space so my system upgrade didn't finish.

planckstein: according to the lddtree libicudata is required by boost-libs (a dependency of blender). My guess is that your system is not fully upgraded and boost-libs still links to the old version of the library.

Hi there! This package built for me, but I got the following error when running it: blender: error while loading shared libraries: libicudata.so.55: cannot open shared object file: No such file or directory Does anyone know what I can do to fix this error? Thanks!

Awesome! Thanks for all the work you do. I will try it again shortly.

Thanks for reminding me. I made a patch to makepkg that allows blender-git to build: https://lists.archlinux.org/pipermail/pacman-dev/2015-January/019837.html

Still having the same problem as escentrix with the blender-addon.git folder as well. Has there been a solution yet?

There seems to be a bug in makepkg. I will investigate that more.

I'm trying to get this compiled ('yaourt -S blender-git' as well as manual makepkg) but I keep running into: ------ ... ==> Validating source files with md5sums... blender ... Skipped blender-addons.git ... Skipped blender-addons-contrib.git ... Skipped blender-translations.git ... Skipped scons.git ... Skipped blender.desktop ... Passed ==> Extracting sources... -> Creating working copy of blender git repo... Cloning into 'blender'... done. -> Creating working copy of blender-addons git repo... Cloning into 'blender-addons'... done. /usr/bin/makepkg: line 1593: cd: blender-addons.git: No such file or directory ==> ERROR: Failed to change to directory blender-addons.git Aborting... ==> ERROR: Makepkg was unable to build blender-git. ------ Everything was downloaded okay and I can see that blender-addons.get is there. Not sure what to do next.

mrunion: I just tried it and it compiles fine. Thank you for all the work on fixing the issue.

The Blender ticket has been marked resolved and it appears they have (or will shortly) fix the issue.

The error I'm getting doesn't necessarily relate to these changes AFAIK. Here is the error: ---------- /tmp/tmp.HuPKkPCapN/blender-git/src/blender/source/blender/blenfont/intern/blf_glyph.c: In function ‘blf_glyph_add’: /tmp/tmp.HuPKkPCapN/blender-git/src/blender/source/blender/blenfont/intern/blf_glyph.c:265:13: error: conversion to ‘int’ from ‘unsigned int’ may change the sign of the result [-Werror=sign-conversion] g->width = bitmap.width; ^ /tmp/tmp.HuPKkPCapN/blender-git/src/blender/source/blender/blenfont/intern/blf_glyph.c:266:14: error: conversion to ‘int’ from ‘unsigned int’ may change the sign of the result [-Werror=sign-conversion] g->height = bitmap.rows; ^ cc1: some warnings being treated as errors source/blender/blenfont/CMakeFiles/bf_blenfont.dir/build.make:123: recipe for target 'source/blender/blenfont/CMakeFiles/bf_blenfont.dir/intern/blf_glyph.c.o' failed make[2]: *** [source/blender/blenfont/CMakeFiles/bf_blenfont.dir/intern/blf_glyph.c.o] Error 1 CMakeFiles/Makefile2:4889: recipe for target 'source/blender/blenfont/CMakeFiles/bf_blenfont.dir/all' failed make[1]: *** [source/blender/blenfont/CMakeFiles/bf_blenfont.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... ---------- As you can see, the problem is that the setting -Werror=sign-conversion is catching an uncast type coersion. Lines 265 and 266 (where the error occurs) are: 265 g->width = bitmap.width; 266 g->height = bitmap.rows; The problem is that g->width/height are type "int", but bitmap.wdith/height are type "unsigned int". That is causing the issue. I tried an explicit cast (I changed the code to g->width = (int)bitmap.width, ... etc.). Blender compiled fine this way. I added "-Wno-error=sign-conversion" to the CXX_FLAGS in my makepkg.conf file and the build failed the same way. (I may have not done this correctly, though, so YMMV.) I have reported this as a Blender bug. (https://developer.blender.org/T42797)

Just to let everybody know, there was a change in default cmake build configs (in main CMakeLists.txt) recently that may be the reason for unexpected build behaviors. Discussion: http://lists.blender.org/pipermail/bf-committers/2014-November/044462.html Commit: https://developer.blender.org/rBbf63e348a2c481fa523466a86dd52cedadc62bc8

Has anyone had any problems building blender in the past 3-4 days? There is an error with a "conversion" at about 52%. The problem is with blf_glyph.c. I think I know the fix, but I am wondering why the code would start failing now, when it seems the Blender code hasn;t changed in a long time. I think it's because of aglibc update, but I haven't dug any further. Does anyone else have a building issue?

It seems so. I updated the PKGBUILD accordingly.

It seems that now we have to also have -WITH_GAMEENGINE=ON if -WITH_PLAYER=ON. Has anyone else experienced this?

reedlaw: I would say that freetype2-infinality should be fixed to provide the same files as the freetype2 package.

Anyone have issues with this and freetype2-infinality? Seems like the infinality bundle installs to /usr/include/freetype2/freetype/ instead of /usr/include/freetype2/. I get this error: In file included from /home/reed/aur/blender-git/src/blender/source/blender/blenlib/intern/freetypefont.c:35:0: /usr/include/ft2build.h:56:38: fatal error: freetype/config/ftheader.h: No such file or directory #include <freetype/config/ftheader.h> ^ compilation terminated.

agapito: it builds fine for me. From the look of it, it looks that there's something wrong with the openimageio package or the openexr package.

My problem is: [ 97%] Built target bf_rna Scanning dependencies of target bf_intern_cycles [ 97%] [ 97%] [ 97%] [ 97%] [ 97%] [ 98%] [ 98%] Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_session.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_python.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_particles.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_curves.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_mesh.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_camera.cpp.o Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_object.cpp.o [ 98%] Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_shader.cpp.o Linking CXX static library ../../lib/libextern_libmv.a [ 98%] Built target extern_libmv Scanning dependencies of target blenderplayer [100%] Building C object source/blenderplayer/CMakeFiles/blenderplayer.dir/bad_level_call_stubs/stubs.c.o Linking CXX executable ../../bin/blenderplayer [100%] Building CXX object intern/cycles/blender/CMakeFiles/bf_intern_cycles.dir/blender_sync.cpp.o /usr/bin/ld: warning: libHalf.so.10, needed by /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libIex-2_0.so.10, needed by /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libIlmImf-Imf_2_0.so.20, needed by /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::setTileDescription(Imf_2_0::TileDescription const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledInputPart::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputPart::writeTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::IStream::IStream(char const*)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::vector<std::string, std::allocator<std::string> > >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::userData() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Attribute::Attribute()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::seconds() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::lineOrder()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::hours() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledInputPart::DeepTiledInputPart(Imf_2_0::MultiPartInputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `typeinfo for Imf_2_0::IStream' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::name() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineOutputPart::writePixels(int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::hasName() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<double> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::perfsPerFrame() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::Header(Imf_2_0::Header const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::count() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::TimeCode(Imf_2_0::TimeCode const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::Header(Imath_2_0::Box<Imath_2_0::Vec2<int> > const&, Imath_2_0::Box<Imath_2_0::Vec2<int> > const&, float, Imath_2_0::Vec2<float> const&, float, Imf_2_0::LineOrder, Imf_2_0::Compression)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::InputFile::readPixels(int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::TimeCode()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepFrameBuffer::insert(char const*, Imf_2_0::DeepSlice const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::TimeCode>::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<float> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputPart::TiledOutputPart(Imf_2_0::MultiPartOutputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::TimeCode>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledInputPart::readTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<double> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::InputPart::readPixels(int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::vector<std::string, std::allocator<std::string> > >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledInputPart::readPixelSampleCounts(int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Slice::Slice(Imf_2_0::PixelType, char*, unsigned long, unsigned long, int, int, double, bool, bool)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledInputPart::setFrameBuffer(Imf_2_0::DeepFrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::IStream::~IStream()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<double> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::type() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::MultiPartInputFile::header(int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputPart::OutputPart(Imf_2_0::MultiPartOutputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::operator=(Imf_2_0::Header const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<int> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::operator=(Imf_2_0::KeyCode const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::vector<std::string, std::allocator<std::string> > >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::channels()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledInputFile::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::TimeCode>::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputFile::TiledOutputFile(Imf_2_0::OStream&, Imf_2_0::Header const&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::channels() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OStream::~OStream()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputFile::OutputFile(Imf_2_0::OStream&, Imf_2_0::Header const&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledOutputPart::writeTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<int> > >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepFrameBuffer::insertSampleCountSlice(Imf_2_0::Slice const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::ChannelList::begin() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineInputPart::DeepScanLineInputPart(Imf_2_0::MultiPartInputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<float> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineInputPart::readPixelSampleCounts(int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::globalThreadCount()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::MultiPartInputFile::MultiPartInputFile(Imf_2_0::IStream&, int, bool)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledOutputPart::setFrameBuffer(Imf_2_0::DeepFrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::Header(int, int, float, Imath_2_0::Vec2<float> const&, float, Imf_2_0::LineOrder, Imf_2_0::Compression)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::dataWindow() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::string>::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::isOpenExrFile(char const*)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::MultiPartOutputFile::MultiPartOutputFile(char const*, Imf_2_0::Header const*, int, bool, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::tileDescription() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<int> > >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledInputFile::readTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputPart::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<float> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputPart::writePixels(int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<float> > >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputFile::writeTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::filmType() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<int> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::isOpenExrFile(char const*, bool&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::string>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::frame() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::prefix() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::setGlobalThreadCount(int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `typeinfo for Imf_2_0::OStream' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<std::string>::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<float> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::displayWindow() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Iex_2_0::BaseExc::what() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::ChannelList::insert(char const*, Imf_2_0::Channel const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::MultiPartInputFile::parts() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<double> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledInputPart::TiledInputPart(Imf_2_0::MultiPartInputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Iex_2_0::BaseExc::BaseExc(char const*)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::dropFrame() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputPart::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::KeyCode>::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::TimeCode(unsigned int, unsigned int, Imf_2_0::TimeCode::Packing)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::minutes() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<float> > >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::hasTileDescription() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineOutputPart::DeepScanLineOutputPart(Imf_2_0::MultiPartOutputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineInputPart::readPixels(int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::FrameBuffer::insert(char const*, Imf_2_0::Slice const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<float> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::KeyCode>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::~Header()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::Envmap>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::IStream::isMemoryMapped() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::InputFile::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::IStream::readMemoryMapped(int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::timeAndFlags(Imf_2_0::TimeCode::Packing) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<int> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Iex_2_0::BaseExc::~BaseExc()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<int> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledOutputPart::DeepTiledOutputPart(Imf_2_0::MultiPartOutputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::KeyCode(Imf_2_0::KeyCode const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputFile::writePixels(int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::KeyCode>::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::insert(char const*, Imf_2_0::Attribute const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineInputPart::setFrameBuffer(Imf_2_0::DeepFrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepTiledInputPart::readTiles(int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TiledOutputFile::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::setType(std::string const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::InputPart::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::filmMfcCode() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::ChannelList::end() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<double> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::end() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::Envmap>::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imf_2_0::Envmap>::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::perfOffset() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<float>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepScanLineOutputPart::setFrameBuffer(Imf_2_0::DeepFrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::KeyCode(int, int, int, int, int, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::begin() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::KeyCode::perfsPerCount() const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::InputPart::InputPart(Imf_2_0::MultiPartInputFile&, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<double> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<int> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TimeCode::operator=(Imf_2_0::TimeCode const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Iex_2_0::throwErrnoExc()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<int> > >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<float> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `typeinfo for Iex_2_0::BaseExc' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<int> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<int>::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Matrix44<float> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::isDeepData(std::string const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Channel::Channel(Imf_2_0::PixelType, int, int, bool)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OutputFile::setFrameBuffer(Imf_2_0::FrameBuffer const&)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `typeinfo for Imf_2_0::Attribute' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Header::compression()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<double> >::staticTypeName()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<float> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::OStream::OStream(char const*)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<double> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec3<double> >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::Attribute::~Attribute()' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::DeepSlice::DeepSlice(Imf_2_0::PixelType, char*, unsigned long, unsigned long, unsigned long, int, int, double, bool, bool)' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Vec2<float> >::writeValueTo(Imf_2_0::OStream&, int) const' sin definir /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/libOpenImageIO.so: referencia a `Imf_2_0::TypedAttribute<Imath_2_0::Box<Imath_2_0::Vec2<float> > >::readValueFrom(Imf_2_0::IStream&, int, int)' sin definir collect2: error: ld devolvió el estado de salida 1 source/blenderplayer/CMakeFiles/blenderplayer.dir/build.make:229: recipe for target 'bin/blenderplayer' failed make[2]: *** [bin/blenderplayer] Error 1 CMakeFiles/Makefile2:7020: recipe for target 'source/blenderplayer/CMakeFiles/blenderplayer.dir/all' failed make[1]: *** [source/blenderplayer/CMakeFiles/blenderplayer.dir/all] Error 2 make[1]: *** Se espera a que terminen otras tareas.... Linking CXX static library ../../../lib/libbf_intern_cycles.a [100%] Built target bf_intern_cycles Makefile:146: recipe for target 'all' failed make: *** [all] Error 2

I'm getting a rather uninformativ e build failure: [ 24%] [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/tracking_region_tracker.c.o Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/tracking_plane_tracker.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/tracking_solver.c.o [ 24%] [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/tracking_util.c.o Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/tracking_stabilize.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/unit.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/treehash.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/world.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/writeavi.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/writeframeserver.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/writeffmpeg.c.o [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/navmesh_conversion.c.o Linking C static library ../../../lib/libbf_blenkernel.a [ 24%] Built target bf_blenkernel Makefile:146: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

@agapito changing '-D PYTHON_VERSION=3.4m' to '-D PYTHON_VERSION=3.3m' worked for me.

- Found PNG: /usr/lib64/libpng.so (found version "1.6.10") -- Found Freetype: /usr/lib64/libfreetype.so CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message): Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR) Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE) build_files/cmake/Modules/FindPythonLibsUnix.cmake:182 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:615 (find_package) -- Configuring incomplete, errors occurred! See also "/tmp/makepkg/blender-git/src/blender-build/CMakeFiles/CMakeOutput.log".

machomanultra: good catch.

"SVN version of Blender"?

jean_no: thank you for mentioning that. This package was bit more difficult to create because of the git submodules, so please test it and report any problems with downloading or updating the sources.

Blender has a new infrastructure development since 11/29/2013 ( svn -> git ) http://code.blender.org/index.php/2013/11/new-development-infrastructure/

Yorrd: in that case there must be some different package on which blender depends but which still depends on boost 1.53. You can use lddtree from pax-utils to find the problematic package. My wild guess is that it's openimageio.

stativ: I did several times :S boost is up to date on version 1.54

Yorrd: there was a boost upgrade and you apparently didn't rebuild blender against the new boost. Just rebuild it.

This is what I get when trying to start blender via the console. blender: error while loading shared libraries: libboost_filesystem.so.1.53.0: cannot open shared object file: No such file or directory

That fixed it. I already tried deleting everything and it didn't seem to work. I found I was changing into the wrong directory! Thanks!

Change into the the directory with blender sources (it's $SRCDEST/blender, where $SRCDEST is the directory with PKGBUILD if you haven't changed it) and run "svn upgrade" there. Or just remove all sources and do a new checkout.

Is anyone getting this now... svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/var/abs/local/blender-svn/blender' is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first. I haven't worked on a solution yet, but was just wondering.

Merging into blender-svn. mosra: Leaving a comment here is nice and all, but mailing a merge request to aur-general would have helped reduce the number of deprecated packages in the AUR by one. Please keep that in mind :)

This package is obsolete as Freestyle is now integrated into mainline Blender. Use https://aur.archlinux.org/packages/blender-svn/ instead.

I removed all the sources and rebuilt and it's fine. It's NOT using OPENJPEG by default I think. (But it looks like it is from the linux-config.py -- so maybe some kind of library checker is failing. If it's using the info from linux-config.py, then the include and lib folders are wrong.). I'm getting too old for this I think!

Also, did you know in the source code there is a PKGBUILD for Arch in the /build_files/package_spec/pacman folder? Cool!

Anyone else get this: /var/abs/local/blender-svn/src/blender/source/blender/imbuf/intern/jp2.c:42:22: fatal error: openjpeg.h: No such file or directory #include "openjpeg.h" I'm not enlightened enough at present to know how to check where Blender is looking for it's includes.

The latest CUDA update fixed this problem. Cool!

Anyone else having this issue when building: Scanning dependencies of target cycles_kernel_cuda [ 84%] Generating kernel_sm_20.cubin nvcc warning : Option '--opencc-options (-Xopencc)' is obsolete and ignored, when targeting compute_20, sm_20, or higher /usr/include/c++/4.8.0/cstdlib(178): error: identifier "__int128" is undefined /usr/include/c++/4.8.0/cstdlib(179): error: identifier "__int128" is undefined 2 errors detected in the compilation of "/tmp/tmpxft_00004173_00000000-6_kernel.cpp1.ii". make[2]: *** [intern/cycles/kernel/kernel_sm_20.cubin] Error 2 make[1]: *** [intern/cycles/kernel/CMakeFiles/cycles_kernel_cuda.dir/all] Error 2 make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Is this gcc 4.8.0 related?

mrunion: thank you, fixed.

Didn't the CUDA toolkit change paths to /opt/cuda instead of /opt/cuda-toolkit? It has on my system, aparently!

Building should be fixed now.

So the python 3.3 rebuild has moved. I'll do the update ASAP.

Please do not flag the package out-of-date when it isn't. Also, I will update it no earlier than after python 3.3 leaves testing.

I have confirmed my previous comment it builds with -D PYTHON_VERSION=3.3 using cmake

I believe the python version is mismatched both in the pkgbuild and the binary package from testing, I'm getting: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE): Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE) build_files/cmake/Modules/FindPythonLibsUnix.cmake:128 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:506 (find_package)

I get the same error as arikkus. I've found that this installs fine on a fresh system, but not on one that has had this package installed before (so no upgrading). I wonder why.

So far it's working great on my system. Thanks stativ :)

I get this error when I try to build... Linking CXX executable ../../bin/blenderplayer [100%] Built target blenderplayer cp: cannot stat ‘/home/arikkus/build/blender-freestyle-svn/src/blender/release/plugins/*’: No such file or directory ==> ERROR: A failure occurred in build().

compile fails with: In file included from /usr/include/boost/filesystem.hpp:15:0, from /tmp/yaourt-tmp/aur-blender-svn/src/blender/intern/cycles/util/util_cache.cpp:33: /usr/include/boost/filesystem/config.hpp:16:5: error: #error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3 /tmp/yaourt-tmp/aur-blender-svn/src/blender/intern/cycles/util/util_cache.cpp: In member function 'void ccl::Cache::clear_except(const std::set<std::basic_string<char> >&)': /tmp/yaourt-tmp/aur-blender-svn/src/blender/intern/cycles/util/util_cache.cpp:123:42: error: conversion from 'boost::filesystem::path'type 'std::string {aka std::basic_string<char>}' requested make[2]: *** [intern/cycles/util/CMakeFiles/cycles_util.dir/util_cache.cpp.o] Error 1 make[1]: *** [intern/cycles/util/CMakeFiles/cycles_util.dir/all] Error 2 probably related to http://comments.gmane.org/gmane.comp.video.blender.devel/36298

great to know thanks

Why? My fix (that patch) was committed to blender trunk a few hours after I published it.

dracoroot7: I guess you are experiencing this problem: https://bbs.archlinux.org/viewtopic.php?pid=1126297 It affects all software that uses boost::thread.

svn is up, so I could fix it.

QXQ: yup, the projects.blender.org doesn't work at all. I waiting for it to be up so I can fix the "No such file or directory" issue.

@mrunion I was getting the same issue, however, now I cannot connect to the svn at all. ==> Connecting to Blender SVN server....... Updating '.': svn: E175002: Unable to connect to a repository at URL 'https://svn.blender.org/svnroot/bf-blender/trunk/blender' svn: E175002: OPTIONS of 'https://svn.blender.org/svnroot/bf-blender/trunk/blender': could not connect to server (https://svn.blender.org)

Anyone else getting this: cp: cannot stat ‘/var/abs/local/blender-svn/src/blender/release/plugins/*’: No such file or directory ==> ERROR: A failure occurred in build(). Aborting... That folder/path doesn't seem to exist in the source anymore, but I don't know if it "moved" or it's just not there anymore.

I finally fixed the CUDA detection. I completely forgot about that. mosra: I also thought about some auto detection to determine which kernel should be build. I came to conclusion it's not worth doing – not only I've no idea ho to do that in a simple way, but it also would not be useful in cases when blender was build on a different computer. The same goes for number of make jobs, using one job slows things down if you have plenty of RAM.

I had to add -DCUDA_TOOLKIT_ROOT_DIR=/opt/cuda-toolkit to cmake to make CUDA compilation working. Also compilation of the kernels takes up insane amount of RAM and I think it's better to compile them separately, using only one make job, because otherwise even 4 GB RAM isn't enough :-/ In case someone has similar problems, here's the patch: https://github.com/mosra/archlinux/commit/c849f8170eebae80814d34e9db9dfa3d2e516584 The patch also compiles only one CUDA kernel for one specific card (in my case Nv 330M with CUDA 1.2), because the others are not needed. I don't know how to make the PKGBUILD decide on its own, though.

Works fine here. It was probably just one of those random breakages. It's a development branch after all.

/tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:650:15: UYARI: 'AVFormatParameters::time_base' is deprecated (declared at /usr/include/libavformat/avformat.h:350) [-Wdeprecated-declarations] /tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:650:15: UYARI: 'AVFormatParameters::time_base' is deprecated (declared at /usr/include/libavformat/avformat.h:350) [-Wdeprecated-declarations] /tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:651:15: UYARI: 'AVFormatParameters::width' is deprecated (declared at /usr/include/libavformat/avformat.h:353) [-Wdeprecated-declarations] /tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:651:15: UYARI: 'AVFormatParameters::width' is deprecated (declared at /usr/include/libavformat/avformat.h:353) [-Wdeprecated-declarations] /tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:652:15: UYARI: 'AVFormatParameters::height' is deprecated (declared at /usr/include/libavformat/avformat.h:354) [-Wdeprecated-declarations] /tmp/yaourt-tmp-root/aur-blender-svn/src/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:652:15: UYARI: 'AVFormatParameters::height' is deprecated (declared at /usr/include/libavformat/avformat.h:354) [-Wdeprecated-declarations] make[2]: *** [source/gameengine/VideoTexture/CMakeFiles/ge_videotex.dir/VideoFFmpeg.cpp.o] Hata 1 make[1]: *** [source/gameengine/VideoTexture/CMakeFiles/ge_videotex.dir/all] Hata 2 make: *** [all] Hata 2

mrunion: thanks, fixed.

2.62 is out. There are two lines at the bottom of the PKGBUILD that refers to 2.61. These need to be changed to 2.62 in order for the package not to have a problem with stripping the CUDA files/things.

I've enabled the building of cuda kernels, if the cuda is present at compile time. Unfortunatelly I can't test whether it works, because it seems the blender now requires a card with nVidia compute 1.3, which I don't have.

coyotevz: sorry, but I won't do that. For most people it's a completely useless dependency, especially when it comes from AUR (because more compiling is needed).

Please add 'libspnav' as dependency. Tanks!

after recompiling openimageio-git blender starts fine, thx ;] but with rendering with cycles on gpu (gt 240go) I've got this /usr/bin/nvcc Compiling CUDA kernel ... /usr/share/blender/2.60/scripts/addons/cycles/kernel/svm/svm_texture.h(45): Warning: Pointer parameters must be inlined, so overriding noinline attribute on '_Z7voronoi6float318NodeDistanceMetricfPfPS_' /usr/share/blender/2.60/scripts/addons/cycles/kernel/svm/svm.h(151): Warning: Pointer parameters must be inlined, so overriding noinline attribute on '_Z14svm_eval_nodesP13KernelGlobalsP10ShaderData10ShaderTypefi' /tmp/tmpxft_00001370_00000000-9_kernel.cpp3.i(0): Warning: Optimizing huge function kernel_cuda_path_trace because Olimit has been overridden; compiler may run out of memory or run very slowly .... 100% cpu, lot of memory consuming ... long time after image appears maybe another not recompiled libraries?

I'm glad it helped. These library dependencies can be tricky sometimes.

OK, I paid more attention to what you said. I had NOT recompiled openimageio-git with the new Boost version. I recompiled both openimageio-git and blender and things are back on track. Thanks!

That's strange: []$ yaourt -Qs boost extra/boost 1.48.0-2 [119,74 M] Free peer-reviewed portable C++ source libraries - Development extra/boost-libs 1.48.0-2 [8,94 M] Free peer-reviewed portable C++ source libraries - Runtime []$ blender blender: error while loading shared libraries: libboost_filesystem.so.1.47.0: cannot open shared object file: No such file or directory I built blender just one hour ago (first yaourt -G blender-svn -> makepkg | yaourt -U blender.....)

I did -- at least I think I did! I actually removed and completely re-downloaded everything. I'll give it a try again. Thanks!

mrunion: Blender doesn't have any internal copy of boost. Did you try to do a clean rebuild (ie. remove the build dirs in $srcdir) of blender and openimageio-git? It works for me.

libboost causes issues since Blender is built on 1.47 and Arch has upgraded to 1.48: blender: error while loading shared libraries: libboost_filesystem.so.1.47.0 Is there a way to make Blender build against the system boost version instead of it's own boost version?

stativ, I know. I disabled compile time compilation of the kernels so that cuda-toolkit could be removed from depends but it does build fine. I'd guess issue is probably with your card running out of memory (for that you'd need to limit what versions of CUDA it builds for).

N30N: blender-cycles-svn didn't compile CUDA kernels at compile time, but at runtime. This works with this PKGBUILD too (unless they broke it). There's an "experimental" code in this PKGBUILD which is supposed to compile CUDA at compile time. I guess this is what you meant by the "export lines." It's commented out (ie. the code doesn't have any effect as if it was removed), because it didn't work for me. In other words, if you leave the PKGBUILD as is, CUDA will work in exactly same way as it worked with blender-cycles-svn.

stativ, As I tried to say previously it worked in blender-cycles-svn. Looking at your PKGBUILD it should work if you just remove the export lines.

eribol: I guess you mean that you've uncommented the CUDA code in PKGBUILD. I know about this problem (just read the notice in the code you've uncommented). I'm pretty sure it's caused by the fact CUDA requires gcc 4.4, but external libraries, such as boost and openexr, were compiled with a binary incompatible version of gcc. There are three possible solutions: 1) force nVidia to support current gcc versions officially (the clean way) 2) change CUDA headers so they doesn't choke on newer gcc versions and hope it will not explode. More information could be found on Blender wiki: http://wiki.blender.org/index.php?title=Dev:2.6/Source/Render/Cycles/Building&oldid=157080 (IMO relatively clean way, but it's not guaranteed it will work) 3) recompile your entire system using gcc 4.4 (the ugly and utterly slow way) Or you can let CUDA compile it's kernels at runtime (ie. leave the code commented out). It's slow, but it works. Also results are cached, so the kernels are not recompiled each time you hit the "Render" button.

@stativ, if i use the cude options its give me this error. /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.4/../../../../lib/libboost_thread.so: undefined reference to `std::out_of_range::~out_of_range()@GLIBCXX_3.4.15' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.4/../../../../lib/libboost_regex.so: undefined reference to `std::overflow_error::~overflow_error()@GLIBCXX_3.4.15' collect2: ld How can we fix that? Or is this just temporarily.

> ie. it's GPL2 or any later, which is what license=('GPL') means. Ok, I just noticed that GPL is a link to GPL2 (and this strange convention on the wiki).

N30N: the kernels build fine when they are compiled at a runtime, but when trying to compile them at a compile time, the blender build fails. That's because it's necessary to do entire build using gcc 4.4 which results in errors when linking OpenEXR (and boost probably too). The license is correct, because looking at random file in the blender source three, you will find following: * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. ie. it's GPL2 or any later, which is what license=('GPL') means. > Looking at you PKGBUILD looks like sndfile is missing. I removed that one yesterday, because it didn't seem to be very useful. I've been able to load music files such as ogg or mp3 without libsndfile. Maybe you could give me more insight on this issue.

> it compiles at run time if not done at build I didn't know that. My tests confirms you're right. I tried to modify PKGBUILD to build CUDA kernels if cuda-toolkit is present, but it breaks the build, so I left that code commented out until I get more time to fix it. > You didn't copy other changes? Well, I did all changes on my own. I skimmed through your PKGBUILD only once before deleting it IIRC the changes were some kind of switch to switch branches (I don't see a reason to add it) and enabling some additional libs, such as jack, which I don't want to explicitly enable either, because I'm trying to stick with the defaults most of the time. > This package still has incorrect license According to http://projects.blender.org/scm/viewvc.php/trunk/blender/COPYING?view=markup&revision=41229&root=bf-blender the license is correct. > and missing features found in the standard build (like blenderplayer) Could you please elaborate which features? For now I've added blender player.

QXQ: well, the blender-cycles didn't actually used cuda, because cuda was explicitly disabled in the PKGBUILD, so I think there's no hurt. Stay tuned, I've a PKGBUILD which detects CUDA and enables it when it's found, but I want to test it first.

I had no objections with the blender-cycles-svn package, simply merging the two together. I don't think having CUDA as a dependency is an issue for blender-cycles-svn, especially since cycles is included with Blender now by default. I don't really see the issue if this package adds an opt-depend for CUDA, but OpenCL is the preferred API, and if the release of Cycles is any sign, will hopefully be stable enough for general use soon.

Is someone able to create a blender-git PKGBUILD? It would use less bandwidth at the second build cycle. Here is a thread about the blender-git mirrors http://www.blender.org/forum/viewtopic.php?t=18916&sid=e76d3c0f8a24d1ed21fb1b04834e576f

In case anyone is interested; to build with collada, add these options: -DWITH_OPENCOLLADA=ON -DOPENCOLLADA_ROOT_DIR="/usr" Collada support depends on OpenCollada package, present in aur. For cycles, you need to have openimageio (also in aur) installed and it will appear as an option.

@QXQ; I tried to change render engine but cycles is not there. Only Internal and Game engine is appears. I looked the Render plugin but cycles is not there too. So i installed blender-cycles-svn for cycles for now. And i agree wit N3ON.

I just compiled it, and cycles works fine. You do have to switch to it though (simply change it in the drop down menu at the top of the default setup, near the Scene selection drop down), it appears the old internal render is still the default option. I would disagree with merging the blender-cycles-svn package with this. That one requires extras, such as the CUDA toolkit (which pulls in GCC 4.4), and I think should be relegated to those that would like to use CUDA while we wait for OpenCL. My 9800GTX doesn't perform as well as my Core i7 for rendering with CUDA, and drawing in extra-deps, and adding to compile time for something that will only effect those with recent Nvidia cards seems rather silly.

Is this PKGBUILD using cycles and camera tracking? I installed couple times but it still not using cycles. Anyway wait is over :) Thanks for PKGBUILD file and all blender developers. Blender is shining :)

Compilation works fine here. Maybe it was fixed meanwhile.

Hi. I got this error: /var/abs/local/yaourtbuild/blender-svn/src/blender/source/blender/editors/util/navmesh_conversion.cpp:310:66: error: 'qsort_s' was not declared in this scope make[2]: *** [source/blender/editors/util/CMakeFiles/bf_editor_util.dir/navmesh_conversion.cpp.o] Error 1 make[1]: *** [source/blender/editors/util/CMakeFiles/bf_editor_util.dir/all] Error 2 make: *** [all] Error 2

Thank you, I removed all lcms stuff.

lcms dependency can be removed too.

LCMS was an experiment and the LCMS code has now been removed. Therefore, "-DWITH_LCMS=ON" is at best pointless.

Sorry for the delays, everything should be working again.

Build fails for me: ls: cannot access /tmp/packerbuild-0/blender-freestyle-svn/blender-freestyle-svn/pkg/usr/share/blender: No such file or directory ls: cannot access /tmp/packerbuild-0/blender-freestyle-svn/blender-freestyle-svn/pkg/usr/share/blender: No such file or directory cp: target `/tmp/packerbuild-0/blender-freestyle-svn/blender-freestyle-svn/pkg/usr/share/blender/*/plugins/sequence/' is not a directory ==> ERROR: A failure occurred in package(). Aborting... The build failed.

QXQ: this is done by makepkg automatically.

Just for accuracy you may want to change pkgver pkgver=$(svn info https://svn.blender.org/svnroot/bf-blender/trunk/blender | sed -ne 's/^Revision: //p')

Thank you :)

Fortunately the fix was pretty simple. It works fine now.

And they indeed did.

Archimage: the executable should be /usr/bin/blender. It's possible that they broke build (again :-( ). I'll try to build it to see what happened.

It doesn't work. there's a mistake with a folder /*/plugin. After modifying it needs root permissions Even after compiling, it doesn't work, where's the executable ?

Splex: I guess it is possible but I'm not sure whether it's worthy the work (Blender's build system is sometimes a bit chaotic).

Any chance you could make this not conflict with the 'extra/blender' package?

Updated. I've got a replacement part so I'm slowly getting up and running. Actually fixing this PKGBUILD was the first thing (after update) I did.

Finally got it to compile. http://pastebin.com/H8S0NHmb (updated PKGBUILD)

2 All: I know about recent changes. Unfortunatelly my PC is currently broken so I can't update the PKGBUILD.

PKGBUILD should be updated: http://lists.blender.org/pipermail/bf-committers/2011-March/030712.html

You can patch the CMakeLists.txt file with this dirty little hack (add it into the PKGBUILD before cmake is executed): # Temporary solution to fix the python version diff problem cmakelists_file="$srcdir"/blender/CMakeLists.txt sed -i '249d' "$cmakelists_file" ; sed -i '249 i set(PYTHON_VERSION 3.2 CACHE STRING "")' "$cmakelists_file" sed -i '251d' "$cmakelists_file" ; sed -i '251 i set(PYTHON_INCLUDE_DIRS "${PYTHON}/include/python${PYTHON_VERSION}mu" CACHE STRING "")' "$cmakelists_file" sed -i '254d' "$cmakelists_file" ; sed -i '254 i set(PYTHON_LIBRARY python${PYTHON_VERSION}mu CACHE STRING "")' "$cmakelists_file"

Yeah, the python upgrade to 3.2 broke the blender build. Needed to modify the blender cmake build file slightly to make this work. Don't know when blender will be upgrading to python 3.2, but for now at least it is enough to change the version number. [gunnar@xps blender]$ pwd /home/gunnar/PKGBUILDS/blender-svn/src/blender [gunnar@xps blender]$ svn di CMakeLists.txt Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 35222) +++ CMakeLists.txt (working copy) @@ -246,12 +246,12 @@ # No way to set py31. remove for now. # find_package(PythonLibs) set(PYTHON /usr) - set(PYTHON_VERSION 3.1 CACHE STRING "") + set(PYTHON_VERSION 3.2 CACHE STRING "") mark_as_advanced(PYTHON_VERSION) - set(PYTHON_INCLUDE_DIRS "${PYTHON}/include/python${PYTHON_VERSION}" CACHE STRING "") + set(PYTHON_INCLUDE_DIRS "${PYTHON}/include/python${PYTHON_VERSION}mu" CACHE STRING "") mark_as_advanced(PYTHON_INCLUDE_DIRS) # set(PYTHON_BINARY python) # not used yet - set(PYTHON_LIBRARY python${PYTHON_VERSION} CACHE STRING "") + set(PYTHON_LIBRARY python${PYTHON_VERSION}mu CACHE STRING "")

Hello, After last Python upgrade i have this : [ 24%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/nla.c.o /tmp/yaourt-tmp/aur-blender-svn/src/blender/source/blender/blenkernel/intern/nla.c:1579:13: attention : ‘BKE_nla_bake’ defined but not used [ 25%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/node.c.o /tmp/yaourt-tmp/aur-blender-svn/src/blender/source/blender/blenkernel/intern/node.c:31:20: erreur fatale: Python.h : Aucun fichier ou dossier de ce type compilation terminée. make[2]: *** [source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/node.c.o] Erreur 1 make[1]: *** [source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/all] Erreur 2 make: *** [all] Erreur 2 Abandon... ==> ERROR: Makepkg n'a pas pu construire blender-svn.

Builds fine now. But I just noticed that it doesn't have Freestyle integration! The SVN should be pointing to this https://svn.blender.org/svnroot/bf-blender/branches/soc-2008-mxcurioni/

Sorry, I almost forgot about this package... Updated to new buildsystem (CMake) like in blender-svn, updated URL to freestyle integration blog. Should build flawlessly now. And also a nice revision number: 34444 :-)

Is this an SVN build problem (34341) or is it because of my configurations? Python is 3.1.3-1 Traceback (most recent call last): File "scons/scons.py", line 66, in <module> if os.environ.has_key("SCONS_LIB_DIR"): AttributeError: '_Environ' object has no attribute 'has_key'

Just a heads up for whoever has the makesrna step segfaulting: While compiling another branch (the particles-2010 one) I noticed that if I have the -O2 (or -O1) option enabled in /etc/makepkg.conf CFLAGS the crash happens. Removing this will make the crash go away.

eribol: thanks for noticing that. They changed the option which enables ffmpeg during the build. It should be enabled again.

Thank you so much for this PKGBUILD. Can you add sound and video support? I use svn or beta PKGBUILD. But two PKGBUILD does not work with sound or video. Thanks.

Fair enough, I agree.

This should be fixed in OpenShot rather than in Blender. OpenShot shouldn't assume that the blender binary is in the same directory as the data. It's good for making redistributable packages but certainly not good for purity of filesystem. That's why there is FHS.

Can we somehow fix this issue in the package: http://openshotusers.com/forum/viewtopic.php?f=11&t=552&start=0&hilit=blender#p2457 ?

parmegv: It works fine here. You can try a newer checkout, it sometimes happen that some version from subversion cannot compile.

I am not able to install this package. It says: [ 52%] Generating rna_world_gen.c, rna_gpencil_gen.c, rna_space_gen.c, rna_material_gen.c, rna_sensor_gen.c, rna_animviz_gen.c, rna_rna_gen.c, rna_userdef_gen.c, rna_boid_gen.c, rna_actuator_gen.c, rna_pose_gen.c, rna_color_gen.c, rna_sculpt_paint_gen.c, rna_scene_gen.c, rna_curve_gen.c, rna_camera_gen.c, rna_image_gen.c, rna_lamp_gen.c, rna_sound_gen.c, rna_packedfile_gen.c, rna_property_gen.c, rna_nodetree_gen.c, rna_texture_gen.c, rna_controller_gen.c, rna_brush_gen.c, rna_screen_gen.c, rna_action_gen.c, rna_main_gen.c, rna_sequencer_gen.c, rna_test_gen.c, rna_timeline_gen.c, rna_fluidsim_gen.c, rna_animation_gen.c, rna_cloth_gen.c, rna_lattice_gen.c, rna_wm_gen.c, rna_smoke_gen.c, rna_context_gen.c, rna_modifier_gen.c, rna_render_gen.c, rna_ID_gen.c, rna_fcurve_gen.c, rna_vfont_gen.c, rna_constraint_gen.c, rna_particle_gen.c, rna_key_gen.c, rna_nla_gen.c, rna_object_force_gen.c, rna_ui_gen.c, rna_armature_gen.c, rna_group_gen.c, rna_text_gen.c, rna_object_gen.c, rna_mesh_gen.c, rna_meta_gen.c Running makesrna, program versions $Id: makesrna.c 32252 2010-10-02 14:17:20Z blendix $ /bin/sh: línea 1: 9326 Illegal instruction ../../../../bin/makesrna /tmp/clyde-root/blender-svn/blender-svn/src/blender-build/source/blender/makesrna/intern/ make[2]: *** [source/blender/makesrna/intern/rna_world_gen.c] Error 132 make[1]: *** [source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/all] Error 2 make: *** [all] Error 2 Aborting... error: Build failed

This should now depend on python instead of python3. Does it really need python2 while building? If so, change the makedepend to python2.

>> * added openal to the depends. Thanks

* added openal to the depends. * re-enabled external (distribution) ffmpeg

Official in-source PKGBUILD (for inspiration, dependencies, etc.): https://svn.blender.org/svnroot/bf-blender/trunk/blender/build_files/package_spec/pacman/

Please add 'openal' to dependency list

Arch_Villain: it should work without it. I'll test again.

Got it working. For some reason, I'm not entirely sure of, it wouldn't work until I deleted the binary from /usr/bin and instead symlinked to <<PKGBUILD DIRECTORY>>/src/install/linux2/blender .Now it runs fine. Go figure.

Hmmm... Seems like it's not finding Python, even with PYTHONHOME=/usr/lib/python3.1 and BLENDER_SYSTEM_PYTHON=/usr/lib/python3.1

I also tried setting $BLENDER_USER_CONFIG and $BLENDER_SYSTEM_CONFIG to ~/.blender as well as $BLENDER_USER_SCRIPTS and $BLENDER_SYSTEM_SCRIPTS to ./blender/2.53/scripts Any ideas?

I'm getting the same problem as mosra. When I first tried, Blender complained it couldn't find /scripts/modules. I symlinked from /usr/bin/2.53 to /.blender/2.53 and that went away, but now I still get no interface in Blender and the following in the command line: Traceback (most recent call last): File "/usr/bin/2.53/scripts/modules/bpy/__init__.py", line 29, in <module> from bpy import utils File "/usr/bin/2.53/scripts/modules/bpy/utils.py", line 30, in <module> from _bpy import home_paths, blend_paths ImportError: cannot import name home_paths search for unknown operator WM_OT_context_set_enum, WM_OT_context_set_enum RNA_string_set: OperatorProperties.data_path not found. RNA_string_set: OperatorProperties.value not found. search for unknown operator WM_OT_context_set_enum, WM_OT_context_set_enum RNA_string_set: OperatorProperties.data_path not found. RNA_string_set: OperatorProperties.value not found. search for unknown operator WM_OT_context_set_enum, WM_OT_context_set_enum RNA_string_set: OperatorProperties.data_path not found. RNA_string_set: OperatorProperties.value not found. search for unknown operator WM_OT_context_set_enum, WM_OT_context_set_enum ..........etc..............

No need to apologize. It's still under heavy development so weird bugs may happen.

It works for me randomly, sometimes Blender starts with the UI, sometimes not, weird. Now I tried to remove the symlink and it works without it too... I'm sorry about that, it's probably problem with my system. No symlink is needed.

mosra: It seems that I still didn't get it. When I start current blender with empty home directory, I can access all import/export scripts. I can see the scripts shown in the User Preferences/Add-Ons, where I can enable them. I tried the mesh gears add-on script and it worked normally. I didn't have to make any symlink.

mosra: Oh, I got it. I'll take a better look.

mosra: I just tested it and it works fine here (GUI looks normal). I even created a new user to test it with completely empty home. I fixed the problem which caused the plugins to install in /usr/share/blender/*/plugins

Yes, it works without ~/.blender, but it looks for the files in different directory (/usr/share/blender/2.5/) than where they are installed (/usr/share/blender/2.53/).

When I install blender on clean system (without ~/.blender), the blender starts with empty UI. I went through logs and found that blender looks in /usr/share/blender/2.5/ for scripts but they are installed into /usr/share/blender/2.53/. Simple symlink 2.5 -> 2.53 solved that. Also I looked into pacman -Ql blender-svn and saw that sequence and texture plugins are installed into /usr/share/blender/*/plugins (the widcard * somehow didn't expand to 2.53). Fixed PKGBUILD: http://aur.pastebin.com/HEHc2RJ3 (ugly, the version string could be obtained automatically). Thanks for updating.

miffe: Try to remove CMakeCache from $srcdir/blender-build (or the blender-build completely)

It works now if I run cmake manually, but when it's run from makepkg it still detects sse2. Really weird. % cmake -DCMAKE_INSTALL_PREFIX=/usr /home/miffe/blender-svn/src/blender -- Detecting SSE support -- ...SSE support found. -- ...SSE2 support missing. % makepkg -- Detecting SSE support -- ...SSE support found. -- ...SSE2 support found.

A patch was commited against the sse2 bug (r31233). Please try updating :)

The bugreport is here https://projects.blender.org/tracker/index.php?func=detail&aid=23257&group_id=9&atid=498 Btw, the .install file says "This package brings SVN Blender compiled with scons."

Probably because of things like this (and others): IF(WITH_RAYOPTIMIZATION AND SUPPORT_SSE_BUILD) SET(PLATFORM_CFLAGS " -msse -msse2 ${PLATFORM_CFLAGS}") ADD_DEFINITIONS(-D__SSE__) ADD_DEFINITIONS(-D__MMX__) ENDIF(WITH_RAYOPTIMIZATION AND SUPPORT_SSE_BUILD) It seems sse2 is harcoded in many places in the cmake files. I'm not sure if it's a requirement or an oversight. Btw, sorry for the delay miffe, been a bit busy =) Anyways, glad it compiles for you

Adding -DWITH_RAYOPTIMIZATION:BOOL=OFF to cmake makes it compile without SSE. I'll open a bugreport with blender.

Now i get this when building: Running makesrna, program versions $Id: makesrna.c 30999 2010-08-03 05:14:59Z campbellbarton $ /bin/sh: line 1: 18684 Illegal instruction ../../../../bin/makesrna /home/miffe/blender-svn/src/blender-build/source/blender/makesrna/intern/ make[2]: *** [source/blender/makesrna/intern/rna_group_gen.c] Error 132 make[1]: *** [source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/all] Error 2 make: *** [all] Error 2 Aborting... I'm guessing its because blender builds with sse2, but my Athlon XP only has sse support. Anyone know how to turn it off?

Thanks to nullfied I updated PKGBUILD to use CMake instead of SCons. Otherwise I wouldn't even try it, cause I thought it is the same piece of crap as the build using SCons was. I was wrong. Now the PKGBUILD is much cleaner and simpler. I need to do some work on depends though. With SCons I was able to enforce some of the options. With CMake it currently enables options depending on installed software. The resulting build thus may require libraries not currently listed in depends and vice versa.

Well I'm currently working on this (based on the stativ|Lukas Jirkovsky PKGBUILD) http://aur.pastebin.com/dXaUz1ge

Getting this error when building: cp: cannot stat `/home/miffe/blender-svn/src/install/linux2/share/blender/*/plugins/*': No such file or directory Aborting...

Fixed. They broke the FHS compliant build even more, so I had to do some changes to the buildsystem to make it work again.

I think it will take a bit longer than I anticipated. I had to remove the lcms so it builds fine. Unfortunately there is problem with loading some necessary data again so when you start blender there is literally nothing.

currently does not compile

Thanks.

mrunion: I'll take a look at the lcms problem later, I'm learning for an exam arcangeli: it sets compiler flags based on the flags defined in /etc/makepkg.conf

Is it possible to add something like -march=native to CFLAGS and CXXFLAGS, please?

Apologies for another message, but I finally got it to run. I had to: NOT use lcms (modify this in blender.config and update the MD5) I had to add the contents of the /usr/share/blender/2.5 folder to my ~/.blender folder BUT had to name it 2.52! basically, I needed a ~./blender/2.52/* with the stuff from /usr/share/blender/2.5 in it. I'm probably doing something wrong but I don't know what it would be. Any help is definitely appreciated.

Also, why is libgl a dependency It conflicts with nvidia-utils. Could that be the problem with lcms? (I doubt it.)

Do any of you guys get an error concerning lcms? I get... Linking program ==> 'blender' /var/abs/local/blender-svn/src/build/linux2/lib/libbf_blenkernel.a(colortools.o): In function `colorcorrection_do_ibuf': colortools.c:(.text+0x1f63): undefined reference to `cmsCreate_sRGBProfile' colortools.c:(.text+0x1f75): undefined reference to `cmsOpenProfileFromFile' colortools.c:(.text+0x1f82): undefined reference to `cmsErrorAction' colortools.c:(.text+0x1fb0): undefined reference to `cmsCreateProofingTransform' colortools.c:(.text+0x1fce): undefined reference to `cmsDoTransform' colortools.c:(.text+0x1fd6): undefined reference to `cmsDeleteTransform' colortools.c:(.text+0x1fde): undefined reference to `cmsCloseProfile' colortools.c:(.text+0x1ffe): undefined reference to `cmsCloseProfile' collect2: ld returned 1 exit status scons: *** [/var/abs/local/blender-svn/src/build/linux2/bin/blender] Error 1 scons: building terminated because of errors. Aborting...

Good Packaging Work!!

Thank you, fixed.

Also stops on compiling plugins - "mv -f" should be changed to "cp -rf" (or something better).

Makepkg in new pacman 3.4.0 aborts build on first non-successful command, here it stops on applying patch (if it was already patched before, e.g. when rebuilding). Quick dirty fix: http://aur.pastebin.com/71mXMKa7 (line 56). Thanks :-)

Now it should work even when you don't have any MAKEFLAGS specified.

patching file source/creator/SConscript scons: Reading SConscript files ... Command-line arguments No command-line arguments given Command-line targets No targets given, using default Using config file: config/linux2-config.py Using user-config file: user-config.py File "user-config.py", line 5 BF_NUMJOBS = ^ SyntaxError: invalid syntax ==> ERROR: Build Failed. lol

qwert535286: Sorry, I forgot to add md5sums. They are here now. The error messages has nothing to do with blender. They are indicating problems with different packages (peazip, kdebase-workspace and gvim).

When I removed the old versions of blender-svn It appeared these messeges: Error in file "/usr/share/applications/peazip.desktop": "all/all" is an invalid MIME type ("all" is an unregistered media type) Error in file "/usr/share/applications/kde4/kfontview.desktop": "fonts/package" is an invalid MIME type ("fonts" is an unregistered media type) Warning in file "/usr/share/applications/gvim.desktop": usage of MIME type "message/news" is discouraged ("message" is a media type that probably does not make sense in this context)

==> Checking Runtime Dependencies... ==> Checking Buildtime Dependencies... ==> Retrieving Sources... -> Found blender.desktop in build dir -> Found blender.config in build dir -> Found use_usr.diff in build dir ==> ERROR: Integrity checks are missing. ==> ERROR: Makepkg was unable to build blender-svn.

mosra: Thank you for noting that, I didn't realized that it doesn't use MAKEFLAGS. When adding the support for multiple jobs build I improved the PKGBUILD a bit. Improvements: - it uses MAKEFLAGS to determine number of make jobs - correctly switch to FHS - running blender-update-scripts first is no longer required, in fact I removed it - enable fftw and lcms for smoke simulations and color management

Quick fix for multithreaded scons build: http://aur.pastebin.com/A1WJfFmK (see line 50). I don't know if this is clean enough, because $MAKEFLAGS (in /etc/makepkg.conf) can have other parameters than just -jN. But compiling Blender with only one thread is a pain.

I did not. It works now, thanks. I did not see the recommandation because it was hidden between lots of mime errors (if I remember correctly).

Did you run blender-update-scripts as suggested? Otherwise it won't work correctly.

I can't get text in menus... I have an ati graphic card, I tried classic mesa 7.8, gallium and forcing software rendering... still not working. Does someone has a tip for me ? Thanks.

It seems that it has been fixed.

This gets a compile arror at the moment. Temporary workaround at http://bbs.archlinux.org/viewtopic.php?pid=757636

yasm is already included (look at the makedepends). Fakeroot is not really a dependency, it's up to you whether you use it for package building or not.

Seems to need fakeroot and yasm as well as the deps listed here