Bug 107836 (celestia build failure against nvidia-glx) happens because we build and link gtkglext against the wrong opengl implementation. The suggested workaround (build and link celestia against the wrong opengl implementation) is just wrong. gtkglext builds OK against nvidia-glx-1.0.7676-r2, so the opengl-update hack should be retired or made version dependent.
As a Celestia developer and a video driver packager for another distribution, it is my opinion that all programs should be built against X.org's GL, and programs should only use nVidia and ATI's GL libraries loaded via ld.
I should clarify in saying that if things are not linked against X.org's libGL, then things break when a person changes their video card and everything needs to be recompiled. Similar symptoms in bug #123149.
I was looking to remove the switch in gtkglext in #116715 , but I think Pat has a point. I wondered if we already have some policy for this by the X11 team or that we should adopt such a rule ?
I think we should consider building all GL apps against a global set of headers by default. This would make switching implementations in ebuilds unneeded and should prevent problems with building different packs against different headers like reported here.
It isn't just the headers; it's also the link-time LDPATH. I don't necessarily agree that building against Xorg libGl is the right thing to do (I feel perfectly comfortable with rebuilding a few apps when I change GL implementation), but: If we are going to do that it might be better to set CFLAGS and LDFLAGS in the gtkglext ebuild to force building against Xorg libGL, and sneak those CFLAGS/LDFLAGS into the gtkglext pkgconfig. That then also takes care of packages built outside Portage. Cflags: -I/usr/lib/opengl/global/include -I/usr/lib/opengl/xorg-x11/include Libs: -I/usr/lib/opengl/xorg-x11/lib
*** Bug 148019 has been marked as a duplicate of this bug. ***
All 3 major implementations now provide similar (if not identical) headers. That and no news for 3 years, closing FIXED. Thanks
