Package Details: blender-git 3.2.r112632.g5b3a415a59c-1

Git Clone URL: https://aur.archlinux.org/blender-git.git (read-only, click to copy)
Package Base: blender-git
Description: A fully integrated 3D graphics creation suite (development)
Upstream URL: https://blender.org/
Licenses: GPL
Conflicts: blender
Provides: blender
Submitter: stativ
Maintainer: fbrennan (bartus)
Last Packager: bartus
Votes: 72
Popularity: 0.078009
First Submitted: 2013-12-05 10:11 (UTC)
Last Updated: 2022-02-21 14:10 (UTC)

Required by (53)

Sources (7)

Pinned Comments

bartus commented on 2021-02-22 08:00 (UTC) (edited on 2021-02-22 08:08 (UTC) by bartus)

This package is also hosted on GitHub.
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:
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.

Latest Comments

sausix commented on 2022-04-26 09:04 (UTC)

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

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

niobium93 commented on 2022-04-26 07:29 (UTC)

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.

Fog commented on 2022-02-19 02:05 (UTC)

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.

bda commented on 2022-01-05 12:26 (UTC)

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

saburouta commented on 2021-12-08 17:21 (UTC)

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

bartus commented on 2021-12-07 14:45 (UTC) (edited on 2021-12-07 15:23 (UTC) by bartus)

@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.

saburouta commented on 2021-12-07 02:31 (UTC)

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

bartus commented on 2021-12-06 23:35 (UTC) (edited on 2021-12-06 23:46 (UTC) by bartus)

@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.

saburouta commented on 2021-12-06 23:17 (UTC)

@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.

bartus commented on 2021-12-06 21:43 (UTC)

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

saburouta commented on 2021-12-06 21:24 (UTC)

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.

Fog commented on 2021-10-29 05:38 (UTC)

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

xyproto commented on 2021-09-05 10:34 (UTC)

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

bartus commented on 2021-06-01 09:18 (UTC) (edited on 2021-06-01 09:20 (UTC) by bartus)

@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.

mahjong commented on 2021-06-01 07:46 (UTC)

Same issue as @Sinasta

Sinasta commented on 2021-05-20 10:30 (UTC) (edited on 2021-05-20 11:22 (UTC) by 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

sausix commented on 2021-03-02 19:44 (UTC) (edited on 2021-03-02 19:44 (UTC) by sausix)

@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.

carlosnewmusic commented on 2021-03-02 16:22 (UTC)

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

sausix commented on 2021-02-22 14:34 (UTC)

@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.

bartus commented on 2021-02-22 08:00 (UTC) (edited on 2021-02-22 08:08 (UTC) by bartus)

This package is also hosted on GitHub.
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:
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.

bartus commented on 2021-02-22 07:45 (UTC) (edited on 2021-02-22 07:49 (UTC) by bartus)

@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

sausix commented on 2021-02-21 15:07 (UTC)

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

bartus commented on 2021-02-15 20:48 (UTC)

@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 )

sausix commented on 2021-02-13 13:52 (UTC) (edited on 2021-02-13 15:24 (UTC) by sausix)

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.

ElijahLynn commented on 2020-08-31 22:51 (UTC)

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

bartus commented on 2020-06-25 10:44 (UTC)

@sausix I would say outdated

Feel free to report ;)

sausix commented on 2020-06-25 10:37 (UTC)

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

Thanks

bartus commented on 2020-06-25 08:08 (UTC) (edited on 2020-06-25 08:10 (UTC) by bartus)

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

sausix commented on 2020-06-25 00:28 (UTC)

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.

hugegameartgd commented on 2020-05-01 18:50 (UTC)

openjpeg needs to be openjpeg2

sausix commented on 2020-03-12 15:38 (UTC)

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

bartus commented on 2020-03-12 15:26 (UTC)

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

sausix commented on 2020-03-12 04:07 (UTC) (edited on 2020-03-12 04:08 (UTC) by sausix)

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.

berilac commented on 2020-03-09 19:59 (UTC)

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

kureta commented on 2019-12-04 14:39 (UTC)

@bartus thanks for the heads up!

bartus commented on 2019-12-04 07:06 (UTC)

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

bartus commented on 2019-11-03 12:59 (UTC) (edited on 2019-11-03 13:01 (UTC) by bartus)

@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.

berilac commented on 2019-11-03 09:09 (UTC) (edited on 2019-11-03 09:24 (UTC) by berilac)

@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

bartus commented on 2019-11-02 22:53 (UTC)

@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.

berilac commented on 2019-11-02 18:30 (UTC)

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

bartus commented on 2019-11-02 15:50 (UTC) (edited on 2019-11-02 22:53 (UTC) by bartus)

@berilac:

GTX970

Default cube:

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

berilac commented on 2019-11-02 14:15 (UTC)

@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

bartus commented on 2019-11-01 14:26 (UTC)

@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)

berilac commented on 2019-11-01 13:59 (UTC)

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.

bartus commented on 2019-10-24 14:39 (UTC) (edited on 2019-10-24 14:42 (UTC) by bartus)

@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)

rubic commented on 2019-10-24 12:05 (UTC)

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

kureta commented on 2019-10-02 21:25 (UTC)

@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.

kureta commented on 2019-10-02 18:50 (UTC)

@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?

bartus commented on 2019-10-02 16:14 (UTC) (edited on 2019-10-02 18:35 (UTC) by bartus)

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

kureta commented on 2019-09-30 12:43 (UTC)

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

kureta commented on 2019-09-29 21:01 (UTC) (edited on 2019-09-29 21:01 (UTC) by kureta)

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.

bartus commented on 2019-06-17 14:59 (UTC) (edited on 2019-09-07 13:51 (UTC) by bartus)

@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 ;)

fbrennan commented on 2019-01-17 08:20 (UTC)

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 :-)

rigred commented on 2018-12-29 18:36 (UTC)

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.

seo.disparate commented on 2018-12-25 08:24 (UTC)

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.

agapito commented on 2018-12-25 06:36 (UTC)

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

mowcat commented on 2018-12-24 19:54 (UTC)

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

fbrennan commented on 2018-12-23 13:40 (UTC)

@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.

mowcat commented on 2018-12-23 03:16 (UTC)

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

stativ commented on 2018-08-11 19:23 (UTC)

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.

nucularJohn commented on 2018-08-07 14:12 (UTC)

Python is 3.7 now. -DPYTHON_VERSION=3.7m

SpotlightKid commented on 2018-02-24 20:29 (UTC)

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?

berilac commented on 2018-01-27 08:54 (UTC)

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.

berilac commented on 2018-01-19 08:14 (UTC)

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...

Cusith commented on 2017-11-13 15:42 (UTC)

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.

nucularJohn commented on 2017-08-18 14:14 (UTC) (edited on 2017-08-18 14:15 (UTC) by nucularJohn)

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

habys commented on 2017-07-02 22:25 (UTC)

Sorry, I meant SDL, rather than ALSA

habys commented on 2017-07-02 22:20 (UTC)

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

v1n33t commented on 2017-02-01 12:44 (UTC)

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

stativ commented on 2016-08-22 20:10 (UTC)

Good catch!

sandstorm commented on 2016-08-20 06:07 (UTC)

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

stativ commented on 2016-07-28 19:47 (UTC)

Thanks guys! It should compile now.

bartus commented on 2016-07-23 20:51 (UTC)

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

nucularJohn commented on 2016-07-17 17:32 (UTC)

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.

mrunion commented on 2016-07-10 14:13 (UTC)

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.

Roken commented on 2016-06-14 20:05 (UTC)

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

Roken commented on 2015-09-26 07:36 (UTC)

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?

planckstein commented on 2015-05-10 11:41 (UTC)

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

stativ commented on 2015-05-10 09:07 (UTC)

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.

planckstein commented on 2015-05-07 14:20 (UTC)

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!

mrunion commented on 2015-01-27 00:53 (UTC)

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

stativ commented on 2015-01-22 19:54 (UTC)

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

mrunion commented on 2015-01-21 02:33 (UTC)

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

stativ commented on 2015-01-01 12:06 (UTC)

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

escentrix commented on 2014-12-31 16:00 (UTC)

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.

stativ commented on 2014-12-09 21:14 (UTC)

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

mrunion commented on 2014-12-05 00:15 (UTC)

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

mrunion commented on 2014-12-04 02:22 (UTC)

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)

Sanne commented on 2014-12-02 20:41 (UTC)

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

mrunion commented on 2014-11-29 03:11 (UTC)

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?

stativ commented on 2014-11-25 20:58 (UTC)

It seems so. I updated the PKGBUILD accordingly.

mrunion commented on 2014-11-19 03:02 (UTC)

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

stativ commented on 2014-06-06 11:11 (UTC)

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

reedlaw commented on 2014-06-06 03:50 (UTC)

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.

stativ commented on 2014-05-16 08:32 (UTC)

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.

agapito commented on 2014-05-16 00:20 (UTC)

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

Roken commented on 2014-05-13 17:01 (UTC)

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...

karl.lensson commented on 2014-04-02 06:34 (UTC)

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

agapito commented on 2014-03-31 10:46 (UTC)

- 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".

stativ commented on 2014-02-20 09:32 (UTC)

machomanultra: good catch.

commented on 2014-02-16 23:06 (UTC)

"SVN version of Blender"?

stativ commented on 2013-12-05 10:13 (UTC)

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.

jean_no commented on 2013-12-04 11:44 (UTC)

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

stativ commented on 2013-07-16 14:32 (UTC)

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.

commented on 2013-07-16 12:35 (UTC)

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

stativ commented on 2013-07-16 07:00 (UTC)

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

commented on 2013-07-15 15:29 (UTC)

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

mrunion commented on 2013-07-15 02:38 (UTC)

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!

stativ commented on 2013-07-14 14:29 (UTC)

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.

mrunion commented on 2013-07-14 14:03 (UTC)

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.

alucryd commented on 2013-06-25 10:30 (UTC)

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 :)

mosra commented on 2013-05-17 10:57 (UTC)

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

mrunion commented on 2013-05-09 00:30 (UTC)

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!

mrunion commented on 2013-05-09 00:00 (UTC)

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

mrunion commented on 2013-05-08 23:50 (UTC)

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.

mrunion commented on 2013-04-05 23:57 (UTC)

The latest CUDA update fixed this problem. Cool!

mrunion commented on 2013-04-04 03:12 (UTC)

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?

stativ commented on 2012-12-03 10:29 (UTC)

mrunion: thank you, fixed.

mrunion commented on 2012-11-29 03:41 (UTC)

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

mosra commented on 2012-10-27 21:44 (UTC)

Building should be fixed now.

stativ commented on 2012-10-17 10:53 (UTC)

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

stativ commented on 2012-10-17 09:50 (UTC)

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.

commented on 2012-10-17 04:59 (UTC)

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

commented on 2012-10-17 04:06 (UTC)

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)

nikolardo commented on 2012-08-23 19:35 (UTC)

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.

commented on 2012-08-04 07:16 (UTC)

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

commented on 2012-07-28 01:08 (UTC)

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().

commented on 2012-07-27 12:52 (UTC)

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

commented on 2012-07-17 03:19 (UTC)

great to know thanks

Svenstaro commented on 2012-07-16 14:22 (UTC)

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

stativ commented on 2012-07-08 06:19 (UTC)

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

stativ commented on 2012-06-03 16:18 (UTC)

svn is up, so I could fix it.

stativ commented on 2012-06-02 11:35 (UTC)

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.

QXQ commented on 2012-06-02 11:23 (UTC)

@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)

mrunion commented on 2012-06-01 18:42 (UTC)

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.

stativ commented on 2012-05-10 17:49 (UTC)

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.

mosra commented on 2012-04-27 14:29 (UTC)

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.

stativ commented on 2012-04-05 09:49 (UTC)

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

commented on 2012-04-03 15:34 (UTC)

/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

stativ commented on 2012-02-19 17:29 (UTC)

mrunion: thanks, fixed.

mrunion commented on 2012-02-16 19:17 (UTC)

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.

stativ commented on 2011-12-26 13:30 (UTC)

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.

stativ commented on 2011-12-26 12:16 (UTC)

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).

commented on 2011-12-07 02:15 (UTC)

Please add 'libspnav' as dependency. Tanks!

travnick commented on 2011-12-05 19:21 (UTC)

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?

stativ commented on 2011-12-05 18:09 (UTC)

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

mrunion commented on 2011-12-05 17:03 (UTC)

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!

travnick commented on 2011-12-05 16:34 (UTC)

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.....)

mrunion commented on 2011-12-05 15:45 (UTC)

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

stativ commented on 2011-12-05 15:14 (UTC)

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.

mrunion commented on 2011-12-04 16:39 (UTC)

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?

N30N commented on 2011-12-03 10:46 (UTC)

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).

stativ commented on 2011-12-03 08:48 (UTC)

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.

N30N commented on 2011-11-28 15:17 (UTC)

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.

stativ commented on 2011-11-28 13:49 (UTC)

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.

commented on 2011-11-27 19:40 (UTC)

@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.

N30N commented on 2011-11-18 16:03 (UTC)

> 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).

stativ commented on 2011-11-18 14:49 (UTC)

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.

stativ commented on 2011-11-18 12:12 (UTC)

> 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.

stativ commented on 2011-11-17 20:09 (UTC)

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.

QXQ commented on 2011-11-17 19:33 (UTC)

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.

surfhai commented on 2011-11-15 19:40 (UTC)

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

mdias commented on 2011-11-13 05:46 (UTC)

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.

commented on 2011-11-12 16:29 (UTC)

@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.

QXQ commented on 2011-11-12 06:32 (UTC)

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.

commented on 2011-11-11 21:30 (UTC)

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 :)

stativ commented on 2011-09-11 06:10 (UTC)

Compilation works fine here. Maybe it was fixed meanwhile.

commented on 2011-09-09 23:51 (UTC)

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

stativ commented on 2011-05-17 14:06 (UTC)

Thank you, I removed all lcms stuff.

commented on 2011-05-16 14:45 (UTC)

lcms dependency can be removed too.

commented on 2011-05-16 14:08 (UTC)

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

mosra commented on 2011-05-01 08:55 (UTC)

Sorry for the delays, everything should be working again.

nikolardo commented on 2011-04-22 20:59 (UTC)

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.

stativ commented on 2011-03-21 12:08 (UTC)

QXQ: this is done by makepkg automatically.

QXQ commented on 2011-03-21 08:43 (UTC)

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')

commented on 2011-03-08 23:18 (UTC)

Thank you :)

stativ commented on 2011-03-07 08:33 (UTC)

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

stativ commented on 2011-03-07 08:25 (UTC)

And they indeed did.

stativ commented on 2011-03-07 08:17 (UTC)

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.

commented on 2011-03-07 05:40 (UTC)

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 ?

stativ commented on 2011-03-06 09:23 (UTC)

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).

commented on 2011-03-05 08:01 (UTC)

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

stativ commented on 2011-03-04 12:49 (UTC)

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.

commented on 2011-03-03 03:13 (UTC)

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

stativ commented on 2011-03-02 15:26 (UTC)

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

mdias commented on 2011-03-02 15:20 (UTC)

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

krigun commented on 2011-03-01 09:11 (UTC)

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"

krigun commented on 2011-02-27 15:13 (UTC)

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 "")

commented on 2011-02-26 16:04 (UTC)

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.

commented on 2011-01-22 05:22 (UTC)

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/

mosra commented on 2011-01-21 20:45 (UTC)

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 :-)

commented on 2011-01-21 05:48 (UTC)

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'

mdias commented on 2011-01-18 20:41 (UTC)

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.

stativ commented on 2011-01-17 14:19 (UTC)

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

commented on 2011-01-16 00:04 (UTC)

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.

Svenstaro commented on 2010-12-20 12:50 (UTC)

Fair enough, I agree.

stativ commented on 2010-12-19 09:28 (UTC)

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.

Svenstaro commented on 2010-12-14 20:26 (UTC)

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

stativ commented on 2010-10-24 11:20 (UTC)

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

commented on 2010-10-19 19:54 (UTC)

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

Svenstaro commented on 2010-10-19 05:42 (UTC)

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

commented on 2010-09-16 12:36 (UTC)

>> * added openal to the depends. Thanks

stativ commented on 2010-09-13 18:42 (UTC)

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

mosra commented on 2010-09-13 14:36 (UTC)

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

commented on 2010-09-13 13:51 (UTC)

Please add 'openal' to dependency list

stativ commented on 2010-08-30 09:36 (UTC)

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

commented on 2010-08-27 20:06 (UTC)

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.

commented on 2010-08-27 07:05 (UTC)

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

commented on 2010-08-27 06:21 (UTC)

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?

commented on 2010-08-27 06:19 (UTC)

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..............

stativ commented on 2010-08-19 09:28 (UTC)

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

mosra commented on 2010-08-19 09:00 (UTC)

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.

stativ commented on 2010-08-18 17:07 (UTC)

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.

stativ commented on 2010-08-18 16:53 (UTC)

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

stativ commented on 2010-08-18 16:52 (UTC)

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

mosra commented on 2010-08-18 16:41 (UTC)

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/).

mosra commented on 2010-08-18 15:53 (UTC)

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.

stativ commented on 2010-08-15 08:25 (UTC)

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

miffe commented on 2010-08-11 18:42 (UTC)

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.

commented on 2010-08-11 12:10 (UTC)

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

miffe commented on 2010-08-10 02:26 (UTC)

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."

commented on 2010-08-10 02:12 (UTC)

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

miffe commented on 2010-08-10 02:07 (UTC)

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

miffe commented on 2010-08-08 13:51 (UTC)

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?

stativ commented on 2010-08-07 10:59 (UTC)

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.

commented on 2010-08-05 02:43 (UTC)

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

miffe commented on 2010-08-03 01:20 (UTC)

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

stativ commented on 2010-07-17 13:16 (UTC)

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

stativ commented on 2010-07-17 11:33 (UTC)

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.

aberkoke commented on 2010-07-15 18:43 (UTC)

currently does not compile

commented on 2010-07-09 12:17 (UTC)

Thanks.

stativ commented on 2010-07-08 15:09 (UTC)

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

commented on 2010-07-08 11:59 (UTC)

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

mrunion commented on 2010-07-07 03:16 (UTC)

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.

mrunion commented on 2010-07-07 01:04 (UTC)

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

mrunion commented on 2010-07-07 00:21 (UTC)

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...

sironitomas commented on 2010-07-03 04:30 (UTC)

Good Packaging Work!!

stativ commented on 2010-06-27 09:22 (UTC)

Thank you, fixed.

mosra commented on 2010-06-26 10:20 (UTC)

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

mosra commented on 2010-06-26 10:07 (UTC)

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 :-)

stativ commented on 2010-06-15 12:55 (UTC)

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

commented on 2010-06-15 11:13 (UTC)

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

stativ commented on 2010-06-15 11:08 (UTC)

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).

commented on 2010-06-15 11:00 (UTC)

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)

commented on 2010-06-15 10:55 (UTC)

==> 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.

stativ commented on 2010-06-15 10:49 (UTC)

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

mosra commented on 2010-06-15 08:27 (UTC)

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.

Xaap commented on 2010-05-26 13:08 (UTC)

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).

stativ commented on 2010-05-21 05:28 (UTC)

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

Xaap commented on 2010-05-20 17:08 (UTC)

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.

stativ commented on 2010-05-19 12:49 (UTC)

It seems that it has been fixed.

commented on 2010-05-14 18:31 (UTC)

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

stativ commented on 2010-05-14 17:45 (UTC)

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.

commented on 2010-05-14 17:18 (UTC)

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