Hi, all. In Debian I have been using Xephyr to test some applications when virtual desktop is not enough, so far so good.
Now I was trying to do the same in an OSX, so I have opened Xephyr and DISPLAY=:2 xeyes work but Wine windows are not created inside the Xephyr window as if the DISPLAY is completely ignored. Is there any way to make this work?
Best wishes, Bruno
On 23 April 2016 at 11:15, Bruno Jesus 00cpxxx@gmail.com wrote:
Now I was trying to do the same in an OSX, so I have opened Xephyr and DISPLAY=:2 xeyes work but Wine windows are not created inside the Xephyr window as if the DISPLAY is completely ignored. Is there any way to make this work?
You don't mention how you're invoking things exactly, but my first thought would be to make sure you're using winex11 and not winemac.
On Sat, Apr 23, 2016 at 11:43 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 23 April 2016 at 11:15, Bruno Jesus 00cpxxx@gmail.com wrote:
Now I was trying to do the same in an OSX, so I have opened Xephyr and DISPLAY=:2 xeyes work but Wine windows are not created inside the Xephyr window as if the DISPLAY is completely ignored. Is there any way to make this work?
You don't mention how you're invoking things exactly, but my first thought would be to make sure you're using winex11 and not winemac.
Sorry, it was:
Xephyr :2 -screen 640x480x24 DISPLAY=:2 xeyes & DISPLAY=:2 wine winecfg
And right, since I don't use OSX I completely forgot about winemac. I just read Useful Registry Keys page and switched to X11, but now wine does not load at all:
err:x11drv:process_attach failed to load libX11.6.dylib: dlopen(libX11.6.dylib, 266): image not found err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.
This is without setting DISPLAY. Clearly it is a missing dependency that I have to install, but the main issue was this x11/winemac difference, thanks.
On 23 April 2016 at 11:51, Bruno Jesus 00cpxxx@gmail.com wrote:
err:x11drv:process_attach failed to load libX11.6.dylib: dlopen(libX11.6.dylib, 266): image not found err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.
This is without setting DISPLAY. Clearly it is a missing dependency that I have to install, but the main issue was this x11/winemac difference, thanks.
It could also be a library path issue. The easiest way to work around it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should be actual OS X users on this list with more experience there.
On Apr 23, 2016, at 4:59 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 23 April 2016 at 11:51, Bruno Jesus 00cpxxx@gmail.com wrote:
err:x11drv:process_attach failed to load libX11.6.dylib: dlopen(libX11.6.dylib, 266): image not found err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.
This is without setting DISPLAY. Clearly it is a missing dependency that I have to install, but the main issue was this x11/winemac difference, thanks.
It could also be a library path issue. The easiest way to work around it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should be actual OS X users on this list with more experience there.
Yes, but it's potentially complicated.
First, are you using XQuartz or another build of X.org (for example, from MacPorts)? You'd presumably want to point the library path to the libraries of the one you're using.
I generally use XQuartz, so I do:
export DYLD_FALLBACK_LIBRARY_PATH=/opt/X11/lib:/usr/lib
The next question is whether you're running OS X 10.11 (El Capitan). If so, its System Integrity Protection feature will make a nuisance of itself. For security, it strips all DYLD_* variables from the environment when you run a "protected" executable. All system executables are protected, including the shell interpreters. If you are invoking a shell script such as the "wine" script for running Wine from the build tree, then that variable will be stripped. For that particular case, you can put the export command into a .winewrapper file to have it sourced by the shell, which will work. For other cases, you may need to edit your script.
-Ken
On Sat, Apr 23, 2016 at 1:17 PM, Ken Thomases ken@codeweavers.com wrote:
On Apr 23, 2016, at 4:59 AM, Henri Verbeet hverbeet@gmail.com wrote:
It could also be a library path issue. The easiest way to work around it might be DYLD_FALLBACK_LIBRARY_PATH, although I'm sure there should be actual OS X users on this list with more experience there.
Yes, but it's potentially complicated.
First, are you using XQuartz or another build of X.org (for example, from MacPorts)? You'd presumably want to point the library path to the libraries of the one you're using.
I generally use XQuartz, so I do:
export DYLD_FALLBACK_LIBRARY_PATH=/opt/X11/lib:/usr/lib
The next question is whether you're running OS X 10.11 (El Capitan). If so, its System Integrity Protection feature will make a nuisance of itself. For security, it strips all DYLD_* variables from the environment when you run a "protected" executable. All system executables are protected, including the shell interpreters. If you are invoking a shell script such as the "wine" script for running Wine from the build tree, then that variable will be stripped. For that particular case, you can put the export command into a .winewrapper file to have it sourced by the shell, which will work. For other cases, you may need to edit your script.
Thanks you both, using the export worked as expected, and yes this is XQuartz (installed from brew I guess, the computer is not mine). It is running Yosemite so it was not a problem.
-
Bruno Jesus -
Henri Verbeet -
Ken Thomases