Wine and LD_PRELOAD

[Damjan Jovanovic]

On Nov 19, 2007 12:48 AM, Lionel Tricon <lionel.tricon at 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