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 ?
Thanks in advance, Lionel Tricon
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?
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.
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.
So, if you have some ideas ...
__lxstat __lxstat64 __open __open64 __opendir2 __xmknod __lxstat __lxstat64 __open __open64 __opendir2 __xmknod __xstat __xstat64 _xftw _xftw64 access acct canonicalize_file_name chdir chmod chown chroot creat creat64 dlmopen dlopen euidaccess execl __xstat __xstat64 _xftw _xftw64 access acct canonicalize_file_name chdir chmod chown chroot creat creat64 dlmopen dlopen euidaccess execve execvp fopen fopen64 freopen freopen64 fts_open ftw ftw64 get_current_dir_name getcwd getwd getxattr glob glob64 glob_pattern_p lchmod lchown lgetxattr link listxattr llistxattr lremovexattr lsetxattr lstat lstat64 lutimes mkdir mkdtemp mknod mkfifo mkstemp mkstemp64 mktemp nftw nftw64 open open64 opendir pathconf readlink realpath remove removexattr rename revoke rmdir scandir scandir64 setxattr stat stat64 symlink tempnam tmpnam truncate truncate64 unlink utime utimes
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
Sorry for answering a little late.
Lionel Tricon wrote:
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.
I have just (a couple of weeks ago) started a project called Fakeroot-ng. You can get the (extremely preliminary) sources from SVN on http://sf.net/projects/fakerootng.
Fakeroot-ng aims to achieve the same goal as fakeroot and fakechroot, except it uses the ptrace interface rather than the LD_PRELOAD interface, which, as you can see, has lots and lots of problems with non-standard applications.
Fakeroot-ng is extremely far from being complete at the moment, but if you will find it useful, then I can use the extra programming skills.
Shachar
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
-
Damjan Jovanovic -
Lionel Tricon -
Shachar Shemesh -
Stefan Dösinger -
Tomas Carnecky