On Nov 19, 2007 12:48 AM, Lionel Tricon lionel.tricon@free.fr wrote:
On Sunday 18 November 2007 20:14:41 Stefan Dösinger wrote:
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.
Hi Stefan, Thanks for your reply.
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?
Lionel, can you provide us with a list of libraries where LD_PRELOAD does not work correctly? This should help to track down the bad ldopen calls.
In fact, we overload a lot of common system call from the standard libc. We have slightly modified the fackechroot library and we need to trap almost all system calls linked to the filesystem. To give you an idea, all the following system calls are reimplemented so that we can put the software into a jail (in most of them, we only change the local path before calling the real one).
As far as i understand the problem (and with the help of strace), it appears that the wine application ignore the LD_PRELOAD env var (LD_PRELOAD instructs the loader to load additional libraries into a program). I suppose that wine use its own internal mechanisme which is not compatible with the LD_PRELOAD one.
LD_PRELOAD will just affect the wine loader, I don't think wineserver is affected. Try this instead:
wineserver -k export LD_PRELOAD=... wine ...
Also, IIRC, wine already looks for libraries in ../lib/wine relative to the directory which contains the wine executable. If I'm right, then there is no need to deprefix it further with LD_PRELOAD hacks.
Damjan