The OpenGL ES and EGL Functions fail to load, and programs using this feature have a segmentation fault. Reproducible: Always Steps to Reproduce: 1. load "libGL.so.1" using dlsym 2. load the function "eglGetProcAddress" 3. use eglGetProcAddress to load eglGetDisplay Actual Results: The program crashes with the call to eglGetProcAddress. Expected Results: eglGetDisplay should be loaded with eglGetProcAddress A simple solution is already known. This bug involves a missing symbolic link. Currently libGL.so and libGL.so.1 have a symbolic link. The missing symbolic link is to the file, libGL.so.1.2. Creating a symbolic link to the ati driver in the library folder fixes the OpenGL ES/EGL crash problem immediately.
As far as i understand we have 2 options (may be) 1) eselect opengl set ati should do the symlink to libGL.so.1.2 too, if this does broke nothing of course 2) it might be possible to do the symlink in the ati-drivers ebuild, but i'm really scared by file collisions problem this way or 3) we can just wait AMD fixes this issue ;). If i understood well comment 34 in the unofficial upstream bugzilla the issue is the driver is not following the standard. Thank you for the report
On those three options. 1) This should not be a problem. Most systems have only one vendor for graphics card at a time. The only time the vendor may not be the same is when dealing with Laptops that have a Dedicated and integrated graphics card. However, in that case, One of the cards is disabled when the other is active. 2) File collision should not an issue. The only file collision issue i have found would be that eselect undoes the fix to my system every time I update the ati driver... I just updated my system, and the output for my system is as follows when i check for all libGL.so based files. $ ls /usr/lib*/libGL.so* /usr/lib32/libGL.so /usr/lib32/libGL.so.1 /usr/lib64/libGL.so /usr/lib64/libGL.so.1 /usr/lib/libGL.so /usr/lib/libGL.so.1 Notice that libGL.so.1.2 is not in the list. The only other ebuild that has this file is the xorg-x11 driver. However, when switching between the opengl drivers, eselect automatically deletes all copies of libGL.so* 3) Waiting for AMD is not the fastest solution to get the fix out to end users because this can be viewed a distribution package bug. This means that if AMD plans to fix the bug within the driver, it will not be until another six months have passed.
1) this doesn't mean this is a good solution and most is not all. 2) for you, what about the rest of the gentoo users? I'm not sure at all, but the X11 team can say something about that 3) but it is the better one. According to your discovery this is not a distribution issue at all given they don't follow openGL ES specifications and we can explain to users this fact as you done, so they can complain with AMD. Only 2 months for the AMD QA process, not 6 afaik. Given the small ammount of users affected we can wait imho. In the mean time you can easly apply your fix. I'm sorry but this is not trivial imho, so i will wait some words from the X11 team.
This bug is 3 years old. Please report back and reopen if a recent version of ati-drivers still has got these issues.
