Hi, I get the following error: >>> Install esdl-0.93.0314 into /var/tmp/portage/esdl-0.93.0314/image/ category media-libs Found erlang at /usr/lib/erlang Installing esdl-0.93.0314 in /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314 mkdir /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/src mkdir /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/c_src mkdir /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/include mkdir /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/doc mkdir /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/ebin cp priv/* /var/tmp/portage/esdl-0.93.0314/image///usr/lib/erlang/lib//esdl-0.93.0314/priv cp: cannot stat `priv/*': No such file or directory make: *** [install] Error 1 !!! ERROR: media-libs/esdl-0.93.0314 failed. !!! Function src_install, Line 34, Exitcode 2 !!! (no error message)
Hi David. This one seems to be caused by incompatibility between glext.h versions of MESA and NVidia libraries. Try doing: opengl-update xfree emerge esdl opengl-update nvidia (it should work fine with nvidia drivers as well then). Sadly, the configure and Makefile's of the package are not very smart about this issue (or rather NVidia provides incompatible headers), so I dont see an easy fix except to output a warning. Though I'll try to do something.. George
One solution might be to use the latest glext.h from opengl.org or latest mesa release (and install it with XF86/nvidia-glx). AFAIK glext.h only contains defines for the various OpenGL extensions so it shouldn't interfere with any opengl lib. I believe the latest mesa version includes all of nvidias extensions (unless they've added more of them recently).
Ok, I managed to come up with a way to test for what openGL implementation is active. I committed the -r1 ebuild, that checks in nvidia is the one and then does opengl-update dance if yes. However I need your help in testing it, as I do not have nvidia hardware here.. The ebuild is package-masked. You will need to comment out its entry in profiles/package.mask. If it tests out Ok, I will replace the -r0 ebuild with the modified one - the fix is only relevant in certain situations and it is compile-time. No need to force recompilation on users for whom it worked.. George PS Somebody mentioned, that he had X crash when using opengl-update in the midst oif the X session. However this seems to be isolated report and other ebuilds do opengl switch, so I think its better to proceed with a fix rather than just a warning. Nontheless I would appreciate if you could do some X stability assesment (probably like not turning your system off right after the update and letting X run for some time..)
The system's been up for a while and so far everything seems to be working. I've run some OpenGL apps as well and they function properly.
Hi David. Thanks for testing! I unmasked the fix, replacing the old ebuild. Closing the bug. George