@Robynsveil Hi, Yes it’s XUbuntu 12.04 and i have no problems with that script it runs ok and compile and install libs without errors on opt/lib. I have errors when build blender … i left cmake default configuration for right now, just copied the boost from opt/lib to my usr/lib folder, but i think it’s some mismatch between version of some other depended libs in my system. And errors i get i think are related to boost and maybe trunk source need more updated libs… I’m not coder just simple user… Regards
P.S. Now blender compiled but with Cycles deselected in cmake configuration… 
So i think i need wait some time during everything will be working again
BLARGH. this is weird. i’m not sure i understand the situation. how on earth are people still putting up Linux builds on graphicall? how are THEY compiling successfully? i tried using only libs i built myself, but that never worked any more than using those from trunk. and now svn isn’t providing libs for linux at all? i wonder what the devs who do their work in Linux are doing to compile successfully?
YAY, a fellow sufferer!! 
The same question I’ve been asking myself, Joel! Clearly they know something we don’t. I mean, I don’t know perl enough to fix that script I mentioned in the other thread, but those on Ubuntu 12.10 appear to have no trouble sh-running it, whilst for me in Mint 13 it spits the dummy with a “got a ‘(’, expected a ‘}’” …missing close bracket… error. How can this thing be?
Have you been successful running that install_devs.sh script?
I build trunk and GSOC bratwurst on Ubuntu 12.10 and Fedora 17 with no problems. The deps are from the install script and they just worked 
Maybe you could ask the devs on the mailing lists/IRC?
Thanks for your answer, James.
The actual script failed for me during execution with the syntax error as described above. So, it wasn’t due to missing files, it was due to how the perl script was being parsed.
I’m wondering if they changed something in the 12.10 perl parser, within which this script might have been written, but previous versions of variants of Ubuntu (such as 12.04, upon which Mint 13 is based) will not parse the same way? Perhaps?
Good suggestion on the IRC idea… might need to go there next.
i was just now able to compile successfully on Mint 13, with OSL support no less. i might go ahead and .tar this build and upload it to graphicall just so i can recover it if this all goes wrong again plus, there are no other builds up on graphicall with OSL support yet.
i finally got the install-deps.sh script to work by deleting my own installation of OpenEXR in /usr/local (that was the only thing hanging me up. i’m not sure why you were getting the weird syntax error, @Robynsveil - i didn’t get anything like that. weird?) i wasn’t able to get it to compile with OpenCOLLADA for some reason, even though i’ve never had issues getting it to compile with my OpenCOLLADA installation in the past… i didn’t get a useful enough error message to figure out why it didn’t work.
hey JamesNZ, this is offtopic, but what did you have to change in Agus3D’s mist patch to get it to compile successfully? i’ve tried and couldn’t understand the errors i was getting.
:o
Finally figured it out, Joel… sorry to be using bandwidth on this. I was running the command this way:
cd ~/blender-svn/blender/build_files/build_environment/
sh install_deps.sh
The problem was sh. In the recent BlenderNation Developers Notes, they provided a link to the Distro_agnostic instructions and so I copied the Terminal commands … and it worked. Chalk it up to Linux newbie-ism… every time I think I’m getting a handle on things, I get taken down a peg. :eek:
oh yeah, i got hung up on that at first too. took me a while to realize there were different shells with different commands. good thing you found out early on
I hope you don’t mind me asking, Joel: I’m using the cmake_gui to configure / generate this build. I’ve followed the instructions at the end of running that install_deps.sh script about adding the following:
-D BOOST_ROOT=/opt/lib/boost
-D Boost_NO_SYSTEM_PATHS=ON
-D WITH_CODEC_FFMPEG=ON
-D FFMPEG=/opt/lib/ffmpeg
…which, when I run the configure cleans stuff up beautifully, but there is still one unresolved issue with Python, specifically Numpy:
CMake Warning at CMakeLists.txt:1931 (message):
PYTHON_NUMPY_PATH is invalid, numpy not found in
‘PYTHON_NUMPY_PATH-NOTFOUND’ WITH_PYTHON_INSTALL_NUMPY option will be
ignored when installing python
Not sure what Numpy does or if it’s essential or what to do about it. Should I just set:
WITH_PYTHON_INSTALL_NUMPY
to off (no)?
I had to change some of the file paths to do with cycles in the patch. Actually, I just noticed that my build doesn’t have it anymore, probably because of reinstalling fedora I’ll download it again and make the necessary changes, then I can put it up on pasteall.org if you’d like?
@Robynsveil: Numpy is an addon for python that helps a lot when doing large calculations, I believe only one addon uses it though and it’s not enabled by default on windows and linux. You can safely set it to ‘Off’ 
Thanks for that, James… done. Blender has happily compiled, and !!!WOW!!! jpg support!! How good is this, then…
Hi & sorry but I forgot all about this thread! :0
You need to edit ~/blender-svn/build_linux/CMakeCache.txt and toggle any values you want from false to true.
I’ve been puzzling about this issue for some days now and still haven’t figured it out.
I get the same error but blender builds without problems and runs flawlessly!
Edit: nevermind, just read the explanation given above by JamesNZ
Hi all, i just ended whit Reinstaled OS after failed upgrading 12.04 to 12.10… Just spending mooore time to have all my libs for other programs than Blender 
I can build Blender with Cycles (on 12.04 there was errors with boost, so i deselected Cycles for build.) But now insted i have errors fith FFMPEG so i deselected this for right now. BUT Blender and CYCLES work again
for NUMPY On 12.10 i have instaled python3-numpy via synaptic
On 12.04 i just copied the numpy folder from my python instalation to python3 folder on /opt/lib - beacose script doesnt install numpy
Brilliant - thanks for that, RCC. I’ll have a go with that. It seems this new script thing does a lot more copying stuff to system folders (well, sort-of 'system) than what we did before, where everything stayed local.
And thanks for the clue on which CMakeCache.txt file to edit, blendercomp - this is one of those things I was puzzling over for a long time.
I dl’ed a fresh svn, deleted the blender-svn/lib dir, cleared /opt/lib and ran the install deps thru to finish, ran make in Blender, tested, then ran cmake-gui …/blender in ./build_linux and customized. A clean install really made a difference and even cycles builds fine now. Scons is completely discombobulated - don’t even try to use that. It still looks for the blender-svn/lib dir even tho it’s deprecated and is not remotely funcitonal.
Yeah, I find cmake to be the most reliable.
I guess it was time to invoke some mechanism to update dependencies: I believe we were on Boost 1.35 (the pre-build flavour) and they had moved on. I guess when we’re told to, we can run that instal_deps.sh script again to update all the dependencies?
1.35? this is kind of irrelevant to the discussion, but i think it was actually boost 1.49 that was in the trunk libs. i’m kind of confused why they changed the way we get libs?
if you look here with a browser
https://svn.blender.org/svnroot/bf-blender/trunk/lib/
you’ll see the directories for linux libs doesn’t exist (as of 11-12-12 morning in US)
I guess their fixing stuff and I’ll have to wait
I’m setting up a new box and have nothing to fall back on