Igor Pechtchanski wrote:
> On Mon, 1 Mar 2004, Harold L Hunt II wrote:
>
>>As I mentioned in my email about enabling indirect OpenGL acceleration,
>>there are some problems when trying to link to -lopengl32.
>>
>>I tracked this down to problems with the way that
>>/usr/include/w32api/GL/gl.h decorates the function declarations for the
>>gl* functions. There are some collisions between the way that the
>>standard windows headers define WINGDIAPI and APIENTRY and the way that
>>gl.h expects them to be.
>>
>>However, the problem is a little trickier than just that: I added a call
>>to glPixelStorei in Xserver/hw/xwin/InitOutput.c (without #including any
>>opengl headers) and instead made my own prototype for glPixelStorei. If
>>I made it:
>>
>>void __stdcall glPixelStorei (unsigned int, int);
>>
>>then the linker would complain about how it had to fixup a reference to
>>glPixelStorei as _glPixelStorei@8. But that is exactly what the
>>__stdcall was supposed to do, so I am getting a little confused about
>>why the prototype was being ignored.
>>
>>I need an expert on __stdcall and w32api headers to give me a hand here.
>> Igor, I saw a post you made on this subject before, so I am counting
>>on you :)
>>
>>Once this little trick is solved we will have to figure out how to get
>>the proper headers in exports/include/GL/; that directory currently
>>getes some Mesa headers in it. I'm not sure if we can cleanly disable
>>that and point to the w32api OpenGL headers instead.
>>
>>Harold
>
>
> Harold,
>
> I'm by no means an expert, and I can't seem to reproduce it. Could you
> please post the exact gcc invocation that exhibits these symptoms?
> Looking at ld's info page, there are a couple of options that could be
> passed to the linker to modify this behavior. It may also be a problem
> with the import lib, for all I know... Is the build seeing the right
> libraries?
>
> Also, the GL/gl.h header doesn't actually use WINGDIAPI, and GLAPI is
> defined to be "extern" on Cygwin. Your declaration, however, seems
> correct. Just for kicks, could you try reverting to including GL/gl.h in
> Xserver/hw/xwin/InitOutput.c and run the build command for that file with
> a "-E" in CFLAGS? That should produce a preprocessed version of
> Xserver/hw/xwin/InitOutput.c, so you can see exactly how glPixelStorei is
> declared.
I have attached a demo program and Makefile that closely models the way
that XWin.exe is built: it builds a static library and links that static
lib and some system libs into an executable, using most of the
compilation flags that are being used when building XWin.exe and
libXWin.a. Only one problem: it doesn't have any problems! :)
The demo program can #include <windows.h> and it can #include <GL/gl.h>,
or it can leave both of those out and just include the resulting
prototype for glPixelStorei:
void __attribute__((__stdcall__)) glPixelStorei (unsigned int, int);
Both of these approaches work just fine.
I included the above prototype in InitOutput.c (and did another test in
winshadgdi.c to be sure), did not include <GL/gl.h> and checked the
preprocessed file to make sure that the glPixleStorei prototype came
through exactly as it was in the source. The program links to that
function (however, I was able to achieve this before doing something
similar), but I still get this silly warning that I do not get from the
demo program:
Warning: resolving _glPixelStorei by linking to _glPixelStorei@8
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
I can't just ignore this warning because we call tons of other stdcall
functions in Win32 DLLs (such as BitBlt from winshadgdi.c) and their
prototypes look identical to the one above for glPixelStorei. So
something weird is going on that is causing libopengl32.a to misbehave
for stdcall functions while all other libraries are working just fine
with stdcall functions. This unexplained discrepancy bothers me.
I have checked the symbols from libgdi32.a and libopengl32.a and they
look the same... so this doubly bothers me.
Detailed commands are below for those that are interested.
Harold
InitOutput.o command
====================
gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../programs/Xserver/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/shadow -I../../../../programs/Xserver/miext/layer -I../../../../programs/Xserver/include -I../../../../programs/Xserver/os -I../../../../include/extensions -I../../../../exports/include/X11 -I../../../../programs/Xserver/render -I../../../../programs/Xserver/randr -I../../../.. -I../../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFree86Server -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXWIN_CLIPBOARD -DXWIN_MULTIWINDOW -DDDXOSRESET -DINCLUDE_ALLOCA_H -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DDDXTIM!