On Nov 19, 2007 12:48 AM, Lionel Tricon <[EMAIL PROTECTED]> 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
