new blender become stable so I emerge it. and it fails on this: gcc -Xlinker -export-dynamic -pthread -o blender /tmp/portage/blender-2.41/work/build/linux2/source/creator/dynamic_buildinfo.o -L/tmp/portage/blender-2.41/work/build/linux2/lib -Llib -L/usr/lib/python2.4/config -L/usr/lib -L/usr/lib -L/usr/lib -L/usr/lib -L/usr/lib -L/usr/X11R6/lib -lblender_creator -lblender_blendersrc -lblender_render -lblender_yafray -lblender_renderconverter -lblender_radiosity -lblender_BSP -lblender_blenkernel -lblender_LOD -lblender_IK -lblender_ONL -lblender_elbeem -lblender_readblenfile -lblender_img -lblender_bop -lblender_blenkernel -lblender_blenloader -lblender_blenpluginapi -lblender_imbuf -lblender_avi -lblender_blenlib -lblender_makesdna -lblender_kernel -lblender_GHOST -lblender_STR -lblender_guardedalloc -lblender_CTR -lblender_MEM -lblender_MT -lblender_BMF -lsoundsystem -lfreetype -lz -lblender_FTF -lextern_ftgl -lfreetype -lz -lKX_blenderhook -lKX_converter -lPHY_Dummy -lPHY_Bullet -lPHY_Physics -lKX_ketsji -lSCA_GameLogic -lRAS_rasterizer -lRAS_OpenGLRasterizer -lblender_expressions -lSG_SceneGraph -lblender_MT -lKX_blenderhook -lKX_network -lblender_kernel -lNG_network -lextern_bullet -lNG_loopbacknetwork -lPHY_Sumo -lPHY_Physics -lblender_MT -lextern_solid -lextern_qhull -lblender_python -lpython2.4 -lSDL -lpthread -lpng -ljpeg -lz -lopenal -lalut -lm -lutil -lstdc++ -lGL -lGLU /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lalut collect2: ld returned 1 exit status scons: *** [blender] Error 1 scons: building terminated because of errors. I have the newest version of OpenAL and haven`t freealut. Blender 2.41-r1.ebuild have dependency on freealut, but version 'r0' haven`t, but marked as stable. If you need more info (I think emerge --info isn`t interesting,because bug is quite clear), ask ;) this is "answer" to #136784
-r1 will be _the_ stable.
(In reply to comment #1) > -r1 will be _the_ stable. > so, then problem is version number openAL, when portage think that 20051024 is newer than 0.0.8. For me it isn`t problem, I hard-masked old version 2005* in my package.mask but it isn`t "clear" resolution.
ref bug #136368, this is an error in the deps, and the only change between this ebuild and -r1 is the deps. Since the build correctly attempts to use -lalut, I believe the correct course of action is to mark -r1 stable... which via ref bug above has been on hold since 6/13.. for a simple dep change???
r1 was stable and now it is the only ebuild available.
What do you mean? $ emerge -p =media-gfx/blender-2.41-r1 These are the packages that would be merged, in order: Calculating dependencies !!! All ebuilds that could satisfy "=media-gfx/blender-2.41-r1" have been masked
which arch?
x86
the r1 has the following keywords KEYWORDS="amd64 ppc ppc64 ~sparc x86" please sync (you made me afraid of a lost commit =P )
I have run a sync today. Looks like it is masked somewhere else... ?! Also, if I add ~x86 to the /etc/portage/package.keywords to try to fix, I get 'invalid atom' or such.
=_= Looks like I assumed the new openal was out when it isn't at all. I'll restore the r0 and I'd suggest you to not use p.masked libraries ...
?? That is the only way to get blender to compile, and is the whole point of this thread... ?!
Further, openal 0.0.8 is marked stable x86...
it should be p.masked
what does that mean?
openal release has alaut split, blender doesn't expect it and -r1 fixes that issue. Looks like the openal-0.0.8 is somewhat available from the stable profile even if it should stay p.masked till the transition is done. I'll restore the r0 and put a constraint to avoid openal-0.0.8 Hopefully that will fix the problems.
Um, read the initial problem report in this thread again! The blender build DOES expect the split -lalut; because it is missing, the build fails... SHEESH!
sigh, no -r0 didn't and now doesn't check what version of openal you have and please downgrade/upgrade to the snapshot version. OR unmask r1 and emerge it.
It must be very late in your timezone, or you have a very itchy trigger finger to respond to bugzilla. I would suggest some more time spent thinking here. I'll try to help with a problem and solution summary: i) blender (r0) build was failing because the scons build expected split -lalut ii) this split is only available in the most recent openal (0.0.8) and freealut iii) the blender -r1 build claims to fix this, and only differs in its deps. Further, both openal 0.0.8 and freealut are marked stable ...as to your suggestions: a) I cannot 'unmask' blender -r1 because it seems to be 'masked' somewhere else, possibly incorrectly. This is mysterious, as both freealut and openal 0.0.8 are marked stable, and as far as I know, and for me, only blender depends on openal. b) I will not downgrade to a non-working (for the blender build), and obsolete (in time) openal, when the newest one is marked stable. c) There seems to be some confusion as to the -lalut problem initially reported: it is not an ebuild problem, it is an scons REQUIREMENT I suppose you could make a patch to fix the scons problem, or you could correct whatever the problem is with the -r1 build being masked.
To recap, openal is already stable on all arches blender supports but amd64, -r1 is currently masked and -r0 got wiped by error.
and -r1 cannot be unmasked. -r0 will not build unless openal is upgraded, freealut is installed, and a no-deps build is done.
r0 builds with pre split openal. I built it before. You can unmask locally r1 just add it to package.unmask as explained in man portage.
I require openal-0.0.8 and freealut-1.1.0 and this has caused me a little inconvenience and head-scratching too. Why do the openal-20050504-r* ebuilds present themselves as upgrades to openal-0.0.8? openal-20050504-r1 is not masked on my x86 system, only the 20051024 ebuild is and -r1 and 0.0.8 are both marked stable. I have had to use /etc/portage/package.mask to stop the openal-2005*s.
2.41-r1 isn't masked anymore... this should be fixed
