Hi, this is with current CVS: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ../../../src/dlls/d3d8/d3d8.spec basetexture.o cubetexture.o d3d8_main.o device.o directx.o drawprim.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o utils.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o version.res -o d3d8.dll.so -L../../dlls -luser32 -lgdi32 -lkernel32 -ladvapi32 -L../../libs/wine -lwine -ldxguid -luuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port surface.o: In function `IDirect3DSurface8Impl_LoadTexture': /usr/local/src/wine/elf/dlls/d3d8/../../../src/dlls/d3d8/surface.c:577: undefined reference to `glCompressedTexImage2D' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [d3d8.dll.so] Error 2 make[2]: Leaving directory `/usr/local/src/wine/elf/dlls/d3d8' I could only find glCompressedTexImage2DARB in my glext.h (SGI OpenGL 1.2.1). Any clues? -- Thanks, Feri.
I could only find glCompressedTexImage2DARB in my glext.h (SGI OpenGL 1.2.1). Any clues?
Alexandre, Would you accept a patch to provide our own OpenGL headers in the Wine source tree ? From what I know, their licensing is pretty relaxed (I can check though) and it would prevent all the myriads of compiling problems / #ifdef magic we have with GL code in Wine. After, we need to decide if we put them in include/GL/XXX.h and 'ship' them with Winelib or if we put them in include/wine/XXX.h so as to use them only to build Wine but Winelib users will use the standard OpenGL library. Both have problems though (mostly due to the calling convention problems). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer <lionel.ulmer(a)free.fr> writes:
I could only find glCompressedTexImage2DARB in my glext.h (SGI OpenGL 1.2.1). Any clues?
Alexandre,
Would you accept a patch to provide our own OpenGL headers in the Wine source tree ? From what I know, their licensing is pretty relaxed (I can check though) and it would prevent all the myriads of compiling problems / #ifdef magic we have with GL code in Wine.
That seems really overkill. It's OK to define some symbols ourselves when they have well-known values, but I don't think shipping the full headers is really necessary; and I don't see how it would solve issues like the above anyway. -- Alexandre Julliard julliard(a)winehq.org
That seems really overkill. It's OK to define some symbols ourselves when they have well-known values, but I don't think shipping the full headers is really necessary; and I don't see how it would solve issues like the above anyway.
Well, the more 'recent' extensions we will use, the more problems we will have. So, to fix all these 'Wine CVS does not build' issues, we can either : 1) test ALL extensions we plan to use in the configure script and disable on an one-per-one basis. Which is a pain to maintain and not really in-line with what OpenGL provides (as extension should be checked at run-time and not at compile time to have one binary work everywhere). 2) do some 'partial' re-implementation of OpenGL headers in the Wine source tree (which is what is done in the dlls/d3d8/d3dcore_gl.h file) 3) ship ourselves the most up-to-date version of the OpenGL headers (actually, we could only ship glext.h but due to bugs in some vendors' gl.h and glx.h files, it's a bit problematic) which would mean removal of all the #ifdef / #endif in the code and all the re-definition of the constants in the d3dcore_gl.h file. What I prefer in the third solution is its 'simplicity'... I.e. maybe shipping glext.h ourselves is overkill, but at least we will develop against a known target instead of having to each time copy / paste the needed extensions in our own header files one by one. Anyway, it's more Raphael's problem than mine so I will let him continue the discussion if he wishes to :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 April 2004 20:21, Lionel Ulmer wrote:
That seems really overkill. It's OK to define some symbols ourselves when they have well-known values, but I don't think shipping the full headers is really necessary; and I don't see how it would solve issues like the above anyway.
Well, the more 'recent' extensions we will use, the more problems we will have. So, to fix all these 'Wine CVS does not build' issues, we can either :
1) test ALL extensions we plan to use in the configure script and disable on an one-per-one basis. Which is a pain to maintain and not really in-line with what OpenGL provides (as extension should be checked at run-time and not at compile time to have one binary work everywhere).
2) do some 'partial' re-implementation of OpenGL headers in the Wine source tree (which is what is done in the dlls/d3d8/d3dcore_gl.h file)
3) ship ourselves the most up-to-date version of the OpenGL headers (actually, we could only ship glext.h but due to bugs in some vendors' gl.h and glx.h files, it's a bit problematic) which would mean removal of all the #ifdef / #endif in the code and all the re-definition of the constants in the d3dcore_gl.h file.
What I prefer in the third solution is its 'simplicity'... I.e. maybe shipping glext.h ourselves is overkill, but at least we will develop against a known target instead of having to each time copy / paste the needed extensions in our own header files one by one.
Anyway, it's more Raphael's problem than mine so I will let him continue the discussion if he wishes to :-)
:) Well for d3d8, our goal is to be independent from GL headers, having all we need on d3dcore_gl.h header. In future i'll move all gl backend into wined3d (second point from lionel proposals) For the third point, i agree it should be more clean but currently we only use a little subset of openGL APIs.
Lionel
Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAlWZWp7NA3AmQTU4RAnGOAJ4yj2WrCmMElkhoHfrFyOKqlNa1dwCffq0g NjhY/7k9Op9n0kdVZtBJmIM= =0EyC -----END PGP SIGNATURE-----
Hello, --- Alexandre Julliard <julliard(a)winehq.org> wrote:
That seems really overkill. It's OK to define some symbols ourselves when they have well-known values, but I don't think shipping the full headers is really necessary; and I don't see how it would solve issues like the above anyway.
There should only be three headers. In mingw w32api they ship glext.h,gl.h and glu.h in a GL subdirectory. Is anything else needed for Wine? Thanks Steven __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
There should only be three headers. In mingw w32api they ship glext.h,gl.h and glu.h in a GL subdirectory. Is anything else needed for Wine?
Well, in the X11 world, there are also glx.h and glxext.h (the latter needed if we want to use GLX extensions). Lionel -- Lionel Ulmer - http://www.bbrox.org/
participants (5)
-
Alexandre Julliard -
Ferenc Wagner -
Lionel Ulmer -
Raphael -
Steven Edwards