Tomas Carnecky tom at
Tue Nov 20 11:26:33 CST 2007

Stefan Dösinger wrote:
> Am Sonntag, 18. November 2007 17:13:20 schrieb Lionel Tricon:
>> Hi wine list,
>> I am currently working for the next generation of the klik project (1
>> application = 1 file) and we actualy face some troubles with picasa which
>> is running under linux thanks to wine.
>> It seems that wine deal badly with the LD_PRELOAD feature which is one of
>> the main composant we use to virtualize and execute the application (with
>> fuse for the underlying filesystem).
>> Is there a way to force wine to go through LD_PRELOAD (to overload some
>> system calls) ? or this limitation is driven by the architecture ?
> I think wine dlopen()s many libraries instead of linking dynamically to them. 
> This makes the build environment more independent of the runtime environment, 
> and we can provide binary builds with all features enabled, and they will 
> still run if the user's system does not have all the libs.
> We had an issue like that with a long time back, and it was fixed by 
> changing some parameter to dlopen. Does anyone remember what that was, and if 
> this can be done for the other libraries too?

IIRC the problem was that wine did dlopen( and then dlsym()
directly on the returned handle. That made preloading libGL using
LD_PRELOAD impossible. The change that was made was to use RTLD_DEFAULT
instead of the library handle in dlsym().

Now however wine should use RPATH which can be overriden by
LD_LIBRARY_PATH so preloading libraries should be easier. Now it's
possible to use LD_LIBRARY_PATH to load a different libGL, don't know
how it works with other libraries though.

I don't think LD_PRELOAD will ever work as long as wine uses dlsym() on
the handle that dlopen() returns. You could try LD_LIBRARY_PATH though,
or change every wine_dlsym() to use RTLD_DEFAULT and see if that solves
your problems

The details are all fuzzy in my head since it's so long ago when I
fought with LD_PRELOAD/LD_LIBRARY_PATH. But that is the best I can remember.

btw, wine again uses the actual handle in dlsym, I don't know when that
was reintroduced, but don't bother changing it as wine now uses RPATH on
platforms that support it, from dlls/winex11.drv/opengl.c:
... = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0);


More information about the wine-devel mailing list