OpenGL linking problem solved

[Harold L Hunt II]

After thinking about this for a bit I realized the following:

1) The problem is due to the conjunction of the Glx extension module not 
using stdcall when it includes gl.h while the function prototype that I 
put in hw/xwin/InitOutput.c did use stdcall.

2) Without the stdcall in InitOutput.c the link against -lopengl32 would 
fail since those symbols and functions use stdcall.

3) The Glx module does not use stdcall because it expects to be linking 
against the Mesa library, which does not use stdcall.

4) While I had removed the Mesa library from the XWin.exe link command, 
I had left in the Glx library, since I will be linking against that when 
I am using -lopengl32 to provide the OpenGL functions.

Recall that if we decorated the function prototype in InitOutput.c with 
stdcall then the link would work, but the linker would complain that it 
was doing an automatic stdcall fixup for us.  I could not duplicate this 
behavior with a stand alone test program and our links to other Win32 
libraries (such as -lgdi32) that use stdcall did not cause a similar 
warning.

I realized that the Glx library had prototypes for the OpenGL functions 
that were not stdcall, so the function 'foo' would get decorated as 
'_foo'.  The Glx library appeared in the link command before the lib 
that includes InitOutput.c; when the linker got to InitOutput.c it saw 
that the function foo was already defined and that its symbol name was 
_foo and marked it as using stdcall (I think).  The interesting bit here 
is that leaving off the stdcall in InitOutput.c causes the function foo 
to be unresolved.  So, now that the linker has marked 'foo' as using 
stdcall, it can resolve _foo to _foo@8 that resolves in -lopengl32. 
Again, without the stdcall, the linker will instead report that the 
symbol '_foo' could not be resolved.

I formed a theory that removing the Glx library from the link command 
would cause the symbol name for the foo function to be _foo@8 instead of 
_foo and it would resolve to _foo@8 in -lopengl32 without warning.

I just tested my theory by removing the Glx library from the link 
command and #if 0'ing two calls to Glx* functions in 
Xserver/mi/miinitext.c, adding -lopengl32 to the link line, and sticking 
a stdcall prototype for glPixelStorei in InitOutput.c and making a call 
to it.  With Glx included the warning was emitted by the linker; with 
Glx excluded the symbol resolved without warning.

The linking problem is now mostly resolved.  Now we must figure out how 
to get stdcall added to all function definitions for the OpenGL headers. 
  I think one part of this is to just disable building of Mesa, which 
should prevent the included GL/*.h headers from being used in the build. 
  Then we might have to add a -DAPIENTRY=__stdcall or some such to the 
defines for the Glx module (since the Glx module will not be inlcuding 
windows.h, which normally results in APIENTRY being defined correctly on 
Windows).

More often than not it seems that just getting things to build properly 
is 90% of the work for adding support for a new feature to Cygwin/X. 
Getting these final linking issues resolved in a reproducible manner 
will mean that we are probably 50% of the way done with indirect OpenGL 
acceleration... it shouldn't take long after that to get some basic 
demos working.  It will take longer to perfect and polish, but we should 
be able to show people something soon.

Harold