d3d8 CVS doesn't compile

[Ferenc Wagner]

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?

[Lionel Ulmer]

> 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

[Alexandre Julliard]

Lionel Ulmer  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.

[Lionel Ulmer]

> 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

[Raphael]

-----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
> :
> -
>
> 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).
> -
>
> 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)
> - 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-----

[Steven Edwards]

Hello,

--- Alexandre Julliard  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

[Lionel Ulmer]

> 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