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 libGL.so 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(libGL.so) 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);

tom
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel