[Wine] Mac OSX (10.5) & wine w/ OpenGL - Info & Issues

netherby wineforum-user at winehq.org
Fri Aug 22 10:05:06 CDT 2008


Firstly, hello everyone!

I'v been using wine under OSX for some time, using macports to install it and it works quite nicely (except for an issue with windows sliding down the screen, which can be fixed by setting a desktop area in winecfg). Sadly I'v not been able to get OpenGL support working.

(I am using OSX 10.5.4 with XQuartz (http://xquartz.macosforge.org/trac/wiki) 2.3.0, which is based on X.org)

There are currently 3 issues I am aware of using OpenGL with wine on OSX.

1) Linker Error
When building wine the linker is unable to find the libGL.dylib, this can be fixed by passing "-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" to the linker, if you are using macports run "sudo port edit wine" and add that line to the "configure.ldflags-append" section of the port file. The build should now succeed.

2) dlopen() does not search /usr/X11/lib
Wine will try to load libGL.dylib using dlopen(), unfortunately it will not be able to find the library. This is easily fixed by supplying the FULL path to the library instead of just the name (if you are using macports, run "sudo port configure wine" before doing the following), edit the ./include/config.h file in your wine build and find the line "#define SONAME_LIBGL "libGL.1.dylib"", change the last part to include the full path the libGL (it should be in "/usr/X11/lib/"). Wine will now load the library dynamically when needed. (note to macport users: the wine build is located in /opt/local/var/macports/build/ with a really long directory name after that ends with wine/work)

3) glx_version < 1.3
Now the final issue I have come to, is that the version of glx is only 1.2, which wine says "GLX_SGIX_fbconfig extension is unsupported" in. At which point none of the library functions will be looked up and set, causing any calls to those pointers to result in reading of unallocated memory, which is usually a bad thing™

I have not been able to solve problem 3.. I looked at what functions are actually required in ./dlls/winex11.drv/opengl.c, if the version of glx returns okay:

glXChooseFBConfig
glXGetFBConfigAttrib
glXGetVisualFromFBConfig
glXQueryDrawable

The second possibility if the version check fails, is that a call to glxRequireExtension("GLX_SGIX_fbconfig") is true. In which case the same functions listed above are loaded, but have SGIX on the end of them.

So I ran nm on libGL.dylib and it reports there are symbols for both sets of the above functions, with and without SGIX on them. How ever the RequireExtension call is failing and the version check returns 1.2 and also fails. I decided to disable the checks and just try to map the functions, which appears to work, or at least the pointers are not NULL and there are no run-time errors when they load. Unfortunately in my tests the OpenGL context still failed to be set current (I'm guessing it didn't get created at all?)..

At this point I'm out of ideas.. Will the version of glx provided simply not work with wine, even though it has the required function symbols? I'm hoping someone that knows what I'm talking about can provide some insight and ideas =)

Cheers!







More information about the wine-users mailing list