This is the mail archive of the
mailing list for the Cygwin XFree86 project.
OpenGL linking problem solved
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygx <cygwin-xfree at cygwin dot com>
- Date: Fri, 05 Mar 2004 01:28:49 -0500
- Subject: OpenGL linking problem solved
- Reply-to: cygwin-xfree at cygwin dot com
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
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
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.