Crash was happening on windows platforms only and was caused
by some specifics about how CRT works.
Basically, blender and all of the .dll are compiled with /MT
flag, which means blender.exe and all .dll are using separate
environments. This makes it impossible to pass file descriptors
from blender to other dll, because it becomes invalid in the dll.
And this is exactly what was happening: OIIO was trying to open
movie file with all known plugins and one of them was zlib. And
the way OIIO was using zlib API is opening the file using Boost
and passing a file descriptor to zlib. And since zlib was a
dynamic library this lead to general issues using this descriptor
in zlib code.
Solved by linking to zlib statically. This allows to safely pass
file descriptor to zlib API. Alternative would be to compile all
the stuff with /MD flag, but that's much bigger and less robust
way to fix the issue.
Tested on windows using msvc2008, scons plus cmake both 32 and 64
bit versions. Seems to be working fine.
Further tweaks for mingw and msvc2012 could be needed tho.
* Better handling of "multiarch" python stuff (libs also need two different paths).
* Fix Opencollada default paths.
Hopefully this won't break anything...
* Script should now remove relevant dirs in $INST when a package becomes suitable
* Script systematically runs relevant ldconfig commands when building boost/oiio
Only activated for Deb-like distro for now, only tested with testing/amd64. Notes :
* Had to add a hell of patches to ilmbase/openexr/oiio cmake files (some are real, stupid bugs fixing [like files missing in lists or wrong linking order], others are "enhancements" [like being able to compile both static and dyn libs for openexr]).
* Unfortunately, I could not manage to keep oiio static (can't compile osl later, as it does not link all deps of oiio, tiff, jpeg, png, etc.). I’ll try to fix this later, but for now, you'll have to do as with boost (ldconfig).
I won't say here what I think about not having any (reliable) way to really link a static lib into another one... :/
Will test and enable other distro in following day(s), I do not *expect* much difficulties here.
Add numpy installation to blender player configuration,
this is so because player is building first and it installs
python, which prevented numpy installation from blender
configuration.
Added new build option WITH_JACK_DYNLOAD for CMake and
WITH_BF_JACK_DYNLOAD for SCons, which means there'll be
no build-time linking against libjack and getting symbols
from libjack will happen runtime using dlopen and dlsym
tricks.
Alternative would be to use weak linking, but it'll require
having wrapper for preloading libjack.
This new options are disabled by default and they only
intended to be used on linux. Other platforms shall not
be using this and there shall be no functional changes
on non-linux platforms at all.
The script is updated with:
Arch Linux support
Numpy 1.7.0 final
Fedora 17 / 18 support
OpenSUSE 12.2 / 12.3 support
Use FFMPEG from RPM-distro repos
RPM-distro fixes
Removed Schroedinger codec
Fixes for Cmake/Scons config
Reviewed by Sergey and me.
Make it so install directory is being nicely
cleaned before next build, which makes it
automatically removing all old files from
previous installations.
Otherwise linux buildbot fails dramatically.
That revision also leads to msvc runtime libs being removed, will fix this
in separate commit.
Take more respect for such creepy as linux and windows platforms, they're not so bad!
