> > I have made a small hack (attached) that tries to adapt my Solaris C
> > patch to this problem. I havn't for various reason been able to
> > test it so it might (read: will) not work, but it is better than
> > nothing I hope.
>
> OK, some comments on the patch :
>
> 1) you seem to have generated your opengl_norm.c from a 'strange'
> source as it includes the 'glBlendFuncSeparateINGR' function (that
> should not be part of the '_norm.c' file as it is an extension.
> (this is the reason why I could not link in the generated
> libopengl32.so)
Yes. It lacks GL/glext.h as well that is one of the reasons I couldn't
test it. But you have the perl script so just regenerate it.
BTW, it is latest MesaGL package from unstable Debian,
so I don't understand why it lacks GL/glext.h has the
glBlendFuncSeparateINGR.
> 2) it crashes on the first call to an OpenGL function :
>
> Call opengl32.413: wglCreateContext(00002ef0) ret=00418e11 fs=0247
> trace:opengl:wglCreateContext (00002ef0)
> Ret opengl32.413: wglCreateContext() retval=08100460
> ret=00418e11 fs=0247
> Call opengl32.423: wglMakeCurrent(00002ef0,08100460)
> ret=00418e8b fs=0247
> trace:opengl:wglMakeCurrent (00002ef0,0x8100460)
> Ret opengl32.423: wglMakeCurrent() retval=00000001
> ret=00418e8b fs=0247
> Call opengl32.153: glGetString(00001f00) ret=00418ef8 fs=0247
>
> Here, I am going into the debugger with this :
>
> Unhandled exception: page fault on read access to 0x00001f00 in 32-bit
> code (0x00001f00).
Perhaps it is because of the missing @PLT in PIC mode.
> In 32 bit mode.
> 0x00001f00:
> Wine-dbg>bt
> bt
> Backtrace:
> =>0 0x00001f00 (ebp=495ef3e0)
> 1 0x496e22e9 (OPENGL32.DLL.glGetString+0x5) (ebp=4e8b4a80)
>
> So it seems that instead of calling to the glGetString function, we
> instead call the argument of this function...
Yes, we probably must jump in the table instead (@PLT).
