opengl support in wine

Tomas Carnecky tom at dbservice.com
Sun Dec 4 08:20:24 CST 2005


Mike McCormack wrote:
> Mike Hearn wrote:
> 
>> On Thu, 01 Dec 2005 16:12:47 +0000, Tomas Carnecky wrote:
>>
>>> I've had a discussion with someone through this list about wine and 
>>> libGL.so. It was about wine using dlopen("libGL.so") instead of linking
>>> directly with libGL.so.
>>
>>
>>
>> IIRC this was done so CodeWeavers can ship a GL enabled build. I don't 
>> see
>> any reason to change it. Weak linking is usually a good thing.
> 
> 
> ddraw.dll uses dlopen on libGL, because there's code in ddraw that can 
> work without libGL being present, and that is needed for some programs 
> (eg. IE6) to run.  dlopen'ing means Wine compiled on a machine with 
> libGL can be run on a machine without libGL.
> 
> opengl32.dll is directly linked with libGL, since it's not useful 
> without it.
> 
> If you're implementing your own shared library, you can probably try 
> dlopen'ing the functions you need from that first, then falling back to 
> dlopening from libGL.
> 

At least you could do:

  glHandle = dlopen("libGL.so", ...)

but later:

  glXSwapBuffers_Ptr = dlsym(RTLD_NEXT, "glXSwapBuffers");

eg. use RTLD_NEXT instead of the real libGL handle. This would make it 
possible to preload my own library but wouldn't change the weak linking. 
In fact, that's how I've modified my local wine copy, and it worked.

tom



More information about the wine-devel mailing list