OpenGL header problems

Tue Mar 2 01:09:00 GMT 2004

On Mon, 1 Mar 2004, Harold L Hunt II wrote:

> 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!
 E -DFD_SETSIZE=256 -DDDXOSINIT -DDDXOSVERRORF -DDDXOSFATALERROR -DHAS_SHM -DHAS_MMAP -DPROJECTROOT="\"/usr/X11R6\"" InitOutput.c
>
> XWin.exe link command
> =====================
> gcc -o XWin.exe -O2 -fno-strength-reduce -Wall -Wpointer-arith -mwindows -e _mainCRTStartup -L../../exports/lib hw/xwin/stubs.o hw/xwin/XWin.res dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/xwin/libXWin.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a fb/libfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a GL/glx/libglx.a render/librender.a miext/shadow/libshadow.a -L/usr/X11R6/lib ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -L../../exports/lib -lXext -lX11 -lz.dll -lcygipc -lgdi32 -lopengl32 -Wl,--enable-auto-import

Harold,

What about the command that builds the static library that InitOutput.o is
included into?  Does it, by any chance, use a --kill-at linker flag?
Otherwise I'm out of ideas.  If you could either post the whole XWin.exe
make log somewhere or send it to me privately, I'll see if I can spot
something that's different in your test example.  Posting it will, of
course, allow everyone else to examine it as well.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton