Summary: | media-gfx/blender-2.71 - src_install(): .../work/blender-2.71/doc/manpage/blender.1.py: subprocess.CalledProcessError: Command '['.../work/blender-2.71_build/bin/blender', '--help']' returned non-zero exit status -11 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jura <me> |
Component: | Current packages | Assignee: | Julian Ospald <hasufell> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | graphics+disabled, lu_zero, me, O01eg |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log.bz2 |
Description
Jura
2014-07-03 09:16:02 UTC
Created attachment 380090 [details]
build.log.bz2
I remove «colorio» useflag and blender build successful. Maybe depend on #515606? Yes, I had this same issue. If you run the python script by hand used to generate the man page stdout spits out what's necessary. The issue is it returns non-zero and the exception is caught in Python from the subprocess module. The REAL issue is one that's existed in 2.70 as well, when compiled with OpenColorIO blender segfaults pretty early on. check if blender-2.71-r1 solves that (In reply to Julian Ospald (hasufell) from comment #4) > check if blender-2.71-r1 solves that It does not. After the python fails, I get this in dmesg: [1076909.303775] traps: blender[13745] general protection ip:7fa9dcdb3950 sp:7fff3e1dad58 error:0 in libOpenColorIO.so.1.0.9[7fa9dcd66000+f5000] Now strangely if I go to the temp builddir as root and run that same python by hand (without CMake), it builds the manpage successfully. In fact, if I copy that blender binary out to my home directory and launch it as a normal user, this error doesn't appear. Maybe CMake's sandboxing is getting in the way? adam@eggsbenedict ~ $ DISPLAY=:0.0 ./blender Color management: using fallback mode for management connect failed: No such file or directory AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead libpng warning: iCCP: known incorrect sRGB profile I'm trying to reproduce this, but I can't. (In reply to Julian Ospald (hasufell) from comment #6) > I'm trying to reproduce this, but I can't. Ahhh my bad, I think it was still trying to use my local overlay. It looks like your ebuild is forcing a yaml-cpp-0.3.0 to be used in place of 0.5.1. Building with this, now. That's really unfortunate because the binary appears to be working with 0.5.1 it just fails when running that python manpage script generation. According to upstream, it should be possible to have opencolorio with yaml-cpp 0.5.1. Then again, it could be an issue upstream with opencolorio and by launching it with Python's subprocess module we happen to modify the memory layout just enough that the general protection fault occurs. (In reply to Adam Stylinski from comment #7) > (In reply to Julian Ospald (hasufell) from comment #6) > > I'm trying to reproduce this, but I can't. > > Ahhh my bad, I think it was still trying to use my local overlay. It looks > like your ebuild is forcing a yaml-cpp-0.3.0 to be used in place of 0.5.1. > Building with this, now. > > That's really unfortunate because the binary appears to be working with > 0.5.1 it just fails when running that python manpage script generation. > According to upstream, it should be possible to have opencolorio with > yaml-cpp 0.5.1. Then again, it could be an issue upstream with opencolorio > and by launching it with Python's subprocess module we happen to modify the > memory layout just enough that the general protection fault occurs. Oh also even stranger is the fact that that same python man page generation script exits just fine when not launched with portage running CMake. I disabled portage's sandboxing and it seemed to have no effect. Blender is building successfully, though. It kind of feels like a band-aid. I guess this is resolved then? |