On Thu, Nov 20, 2003 at 11:50:13PM +0100, Daniel Skorka wrote:
This patch fixes a problem with bad OpenGL libraries wich uncorrectly report the Extensions they support. Those libs would incorrectly report not supporting glXGetProcAddresARB, on which wine relies for OpenGL extension support. The problem was noticed with libGL from XFree86 4.2 under Linux x86.
Well, this poses the question : what should we do regarding broken libraries Wine depends upon ? Add 'incorrect' code in Wine (although in this case, it's not THAT incorrect :-) ) or report the bug to the library maintainers and wait for them to fix the issue ?
Note that according to some DRI maintainer 'I had forgotten that the old libGL was that broken' :-)
Lionel
Lionel Ulmer lionel.ulmer@free.fr writes:
Well, this poses the question : what should we do regarding broken libraries Wine depends upon ? Add 'incorrect' code in Wine (although in this case, it's not THAT incorrect :-) ) or report the bug to the library maintainers and wait for them to fix the issue ?
We should of course report the bug, but I don't see any reason not to put that workaround in, since it actually makes the code simpler, and I don't see how it would break anything since we check the function pointer anyway.
On Fri, Nov 21, 2003 at 09:32:05AM -0800, Alexandre Julliard wrote:
We should of course report the bug, but I don't see any reason not to put that workaround in, since it actually makes the code simpler, and I don't see how it would break anything since we check the function pointer anyway.
Well, I agree for this case...
I added this check the day I found out that any Mesa-based GL library returns a non-NULL function pointer from glXGetPointerAddress whatever the status of the extension ... which leads to crashes if one actually calls this function without checking first for the presence of the extension.
Lionel
I added this check the day I found out that any Mesa-based GL library returns a non-NULL function pointer from glXGetPointerAddress whatever the status of the extension ... which leads to crashes if one actually calls this function without checking first for the presence of the extension.
Just answering myself to say that the same 'issue' is also present in the D3D code and would need patching too :-)
Lionel