This is the mail archive of the mailing list for the Cygwin XFree86 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

OpenGL linking problem solved

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]