http://bugs.winehq.org/show_bug.cgi?id=10184
Summary: Wine configure script unable to resolve -lGL on Mac OS X 10.5 Product: Wine Version: 0.9.48. Platform: Macintosh OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-opengl AssignedTo: wine-bugs@winehq.org ReportedBy: ryanwalklin@gmail.com
The configure script fails to find /usr/X11/lib/libGL.dylib, which is available on Mac OS X 10.5 if the X11 user and dev packages are installed. Consequently OpenGL is unavailable to Wine.
More correctly Wine should link to /System/Library/Frameworks/OpenGL.Framework/Versions/A/Libraries/OpenGL.dylib, as the /usr/X11/lib library consists of links to the Framework. This can be achieved by directly linking to the framework (-Framework OpenGL -framework GLUT) rather than -lGL and -lGLU on OS X.
http://bugs.winehq.org/show_bug.cgi?id=10184
Sam Pullara spullara@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spullara@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #1 from Ryan Walklin ryanwalklin@gmail.com 2007-11-10 16:39:58 --- Upon further investigation, it would appear that this is due to a linker bug in OS X.
However, applying the workaround at http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5, and placing /usr/X11/lib in the linker search path enables Wine to compile and link with the OpenGl libs. However attempting to run OpenGLs (eg Steam) fails with the following error:
$ wine Steam.exe X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x3f Serial number of failed request: 17 Current serial number in output stream: 17
I accept this may still be an Apple X11 bug, but I'd appreciate it if anyone who knew what was going on could comment.
http://bugs.winehq.org/show_bug.cgi?id=10184
Ryan Walklin ryanwalklin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine configure script unable|Wine unable to use Mac OS X |to resolve -lGL on Mac OS X |OpenGL |10.5 | Version|0.9.48. |0.9.49.
http://bugs.winehq.org/show_bug.cgi?id=10184
Raymond Vetter raymondv@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from Raymond Vetter raymondv@gmx.de 2007-11-13 16:14:01 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=10184
Raymond Vetter raymondv@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |raymondv@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #3 from Ryan Walklin ryanwalklin@gmail.com 2007-11-13 17:15:58 --- Created an attachment (id=9150) --> (http://bugs.winehq.org/attachment.cgi?id=9150) Conversation with Ben Byer
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #4 from Ryan Walklin ryanwalklin@gmail.com 2007-11-13 17:16:47 --- Attached is a conversation between myself, Ben Byer (bbyer@apple.com, Apple's XDarwin maintainer and part of the Core OS team there) via the Apple x11-users mailing list.
Hopefully this is enlightening, as it looks like there is a conflict between the way Wine expects to find various system libs and how things are set up on OS X.
http://bugs.winehq.org/show_bug.cgi?id=10184
bazzoola bazzoola@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bazzoola@gmail.com
--- Comment #5 from bazzoola bazzoola@gmail.com 2007-11-13 20:45:27 --- I have been trying to get OGL to work for a while without luck. However, you might want to check out crossover they got their X11 to work with OS X. I know it works on Tiger. I am not sure about Leopard. May be you can debug this further to find out how crossover did it.
They have their modified wine sources on their website. I tried to use it but it didn't work for me.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #6 from Ryan Walklin ryanwalklin@gmail.com 2007-11-13 22:00:41 --- Thanks bazoola, that hadn't occured to me at all.
I've just finished building the Crossover wine source, and interestingly the exact symptoms occur. The LDFLAG workaround is required to compile in OpenGL support, and Wine was unable to find the X11 libs without using DYLD_FALLBACK_LIBRARY_PATH. Using the DYLD variable, Wine crashed with the same X error (128, Apple-DRI).
I've been through the source diffs with Wine 0.9.34 (which Crossover is based on), and there doesn't seem to be anything in the dll loader code or elsewhere which would account for this.
At the moment I'm leaning toward this being a Mac OS bug, but I'm not sure how far I'm going to be able to get from that side.
I've attached the crash log from Crossover-wine, you can see the 128 error there.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #7 from Ryan Walklin ryanwalklin@gmail.com 2007-11-13 22:02:54 --- Created an attachment (id=9151) --> (http://bugs.winehq.org/attachment.cgi?id=9151) Log of x11drv crash on Crossover/Wine 0.9.34
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #8 from bazzoola bazzoola@gmail.com 2007-11-13 22:23:24 --- I am positive that CrossOver worked fine with OpenGL under Tiger. I have tested hitman2 and an OpenGL benchmark (I can't recall the name).
I tried to find what CrossOver did differently but I couldn't locate it so I waited for leopard to test Xorg7 instead of freex86. I just don't have time to play with it now.
http://bugs.winehq.org/show_bug.cgi?id=10184
Zach D teloiv@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |teloiv@gmail.com
--- Comment #9 from Zach D teloiv@gmail.com 2007-11-17 04:12:36 --- Crossover Mac has it's own X11 environment - If you option + click on CrossOver.app and go to CrossOver.app/Contents/SharedSupport/X11/lib, you'll see that they ship with all the libs - X11, Mesa, GL, etc - that they need. I'm guessing that this was because in Tiger, X11 and the necessary things to run it weren't installed by default and instead of requiring the user to install extra, it was just shipped together.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #10 from bazzoola bazzoola@gmail.com 2007-11-17 16:30:28 --- I am aware that CrossOver users their own X11. I was referring to how they link their wine version with the x11 libs. I believe this is what the bug report is about.
http://bugs.winehq.org/show_bug.cgi?id=10184
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #11 from Roderick Colenbrander thunderbird2k@gmx.net 2007-12-29 18:30:49 --- This is fixed in Wine 0.9.52 according to various users in #winehq and it is confirmed by this patch from Francois Gouget 'configure: Work around an Xcode 3.0 bug when detecting the libGL library.'
http://bugs.winehq.org/show_bug.cgi?id=10184
Ryan Walklin ryanwalklin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #12 from Ryan Walklin ryanwalklin@gmail.com 2007-12-29 19:20:50 --- The configure fix allows Wine to find libGL.dylib during compilation, however is still unable to link to the OpenGL libs at runtime. This is apparently a Leopard linker bug, as per my previous posts of conversations with Ben Byer.
ryan@Firebert[~]DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib msiexec /i ~/Downloads/SteamInstall.msi X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x3f Serial number of failed request: 17 Current serial number in output stream: 17
Note that omitting the dyld variable prevents wine from finding libGL at runtime:
err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support ! err:d3d:WineD3D_CreateFakeGLContext Can't find a suitable iPixelFormat err:d3d:InitAdapters Failed to get a gl context for default adapter err:wine_d3d:WineDirect3DCreate Direct3D9 is not available without opengl
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #13 from Zach D teloiv@gmail.com 2007-12-29 19:28:00 --- Created an attachment (id=9895) --> (http://bugs.winehq.org/attachment.cgi?id=9895) -lGL not found, ./configure and config.log output
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #14 from Ryan Walklin ryanwalklin@gmail.com 2007-12-29 19:31:58 --- You'll note that the line directly below that indicates that the alternate test for libGL added in 0.9.52 is working. The patch does exactly the same thing that the LDFLAG workaround I linked in my first post does. The runtime failure is a separate issue I think.
You'll also note that at the end of your configure there is no "Wine cannot find libGL" error.
http://bugs.winehq.org/show_bug.cgi?id=10184
David Morton mortonda@dgrmm.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mortonda@dgrmm.net
--- Comment #15 from David Morton mortonda@dgrmm.net 2007-12-31 12:08:17 --- Using 0.9.52, I see no obvious configure warnings, but when running a program, I get this at the end:
err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support ! err:d3d:WineD3D_CreateFakeGLContext Can't find a suitable iPixelFormat err:d3d:InitAdapters Failed to get a gl context for default adapter
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #16 from Ryan Walklin ryanwalklin@gmail.com 2007-12-31 16:54:09 --- The following env variable allows Wine to see the GL libs on OS X:
export DYLD_FALLBACK_LIBRARY_BATH=/usr/X11/lib
However you immediately get the X RENDER error I posted previously, and I think this is the heart of the problem.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #17 from David Morton mortonda@dgrmm.net 2007-12-31 18:01:12 --- Confirming what Ryan sees:
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x3f Serial number of failed request: 17 Current serial number in output stream: 17
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #18 from Austin English austinenglish@gmail.com 2008-01-01 12:39:17 --- (In reply to comment #17)
Confirming what Ryan sees:
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls"
Are you using wine 0.9.52? The above error was fixed quite a few releases back...
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #19 from David Morton mortonda@dgrmm.net 2008-01-01 12:55:58 --- yes, see my earlier comment
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #20 from Dmitry Timoshkov dmitry@codeweavers.com 2008-01-01 22:19:35 --- (In reply to comment #19)
yes, see my earlier comment
You need to either run wineprefixcreate, or remove ~/.wine and reinstall the application.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #21 from David Morton mortonda@dgrmm.net 2008-01-02 18:49:43 --- no change, same error.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #22 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-12 07:05:32 --- Can someone attach a WINEDEBUG=+wgl log when starting a simple GL app (http://nehe.gamedev.net/data/lessons/vc/lesson02.zip)? I want a case which shows that DRI error with that ChoosePixelFormat message.
I suspect glXChooseFBConfig and friends aren't getting loaded because Apple isn't properly advertising some GLX strings.
If that is the case then open src/dlls/winex11.drv/opengl.c: if(glxRequireVersion(3)) { pglXChooseFBConfig = (void*)pglXGetProcAddressARB((const GLubyte *) "glXChooseFBConfig"); pglXGetFBConfigAttrib = (void*)pglXGetProcAddressARB((const GLubyte *) "glXGetFBConfigAttrib"); pglXGetVisualFromFBConfig = (void*)pglXGetProcAddressARB((const GLubyte *) "glXGetVisualFromFBConfig"); pglXQueryDrawable = (void*)pglXGetProcAddressARB((const GLubyte *) "glXQueryDrawable"); } else if(glxRequireExtension("GLX_SGIX_fbconfig")) {
replace 'if(glxRequireVersion(3)) {' by 'if(1) {' and recompile.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #23 from David Morton mortonda@dgrmm.net 2008-01-12 07:26:00 --- Created an attachment (id=10180) --> (http://bugs.winehq.org/attachment.cgi?id=10180) log with DEBUG=+wgl
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #24 from Zach D teloiv@gmail.com 2008-01-18 07:18:31 --- (In reply to comment #21)
no change, same error.
I changed the line in src/dlls/winex11.drv/opengl.c (Based off of Wine 0.9.53 sources) to what you suggested, however it didn't change the results with DEBUG=+wgl.
err:wgl:X11DRV_wglGetProcAddress and err:wgl:X11DRV_ChoosePixelFormat still cause problems and prevent OpenGL from being found. They're the same as they are in the log David Morton posted earlier.
If needed, I can grab the latest version from git and try the same suggestion out.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #25 from Ryan Walklin ryanwalklin@gmail.com 2008-01-18 14:12:36 --- Bear in mind that you need to use the LDFLAG workaround in Wine < 0.9.53 so configure can find libGL.dylib under /usr/X11/lib.
Additionally, /usr/X11/lib does not seem to be in the linker search path in Leopard, so you need to either export DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib so that libGL.dylib can actually be found when running wine. (This also finds freetype so you guys don't constantly have to rebuild your font metrics)
Anyway, running wine with the above (ie DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib WINEDEBUG=+wgl wine Lesson2.exe) gives:
ryan@Firebert[~/Downloads/Lesson02]$ DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib WINEDEBUG=+wgl wine Lesson2.exe X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x3f Serial number of failed request: 17 Current serial number in output stream: 17
ie the same error for Steam, and likely the OS X linker bug as I've been saying. Recompiling with the patch suggested by Roderick Colenbrander gives the same output. Note there is no additional output from WINEDEBUG=+wgl, so I don't know whether the root of this error is before any GL code is even called, or whether I'm just not using the flag correctly. ;)
Anyway, the configure error has been fixed, and the runtime inability to find libGL.dylib is because /usr/X11/lib is not in the linker search path. This can be worked around as above. The real issue is the X error above, and might turn out to be an Apple bug, although I note other notable OpenGL linux apps have made it across to OS X (Xbox Media Center and DosBox spring to mind, although they're both using SDL as a GL interface).
Anyway hope this helps.
http://bugs.winehq.org/show_bug.cgi?id=10184
Julian M. mayer.julian@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mayer.julian@googlemail.com
--- Comment #26 from Julian M. mayer.julian@googlemail.com 2008-02-22 12:24:58 --- i filed a bug at the xquartz project in hopes of getting this fixed: http://trac.macosforge.org/projects/xquartz/ticket/65
feel free to append information there so that this doesn't go unfixed.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #27 from Zach D teloiv@gmail.com 2008-02-22 14:33:51 --- The bug report on XQuartz was closed with the message "This is fixed in 2.1.4" - there is more to the problem then just a bug with X in any case (linker problems for example).
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #28 from Julian M. mayer.julian@googlemail.com 2008-02-22 15:44:53 --- there is more to it, but the linker problem has workarounds and the X11 issue even existed on 10.4 where no linker problem was present.
anyhow even with the X11.app package version 2.1.4 i can't get it to work:
acPro:wine-0.9.56 julian$ DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib WINEDEBUG=+wgl ./wine ../Lesson02/Lesson2.exe trace:wgl:X11DRV_WineGL_InitOpenglInfo GL version : 2.0 ATI-1.5.24. trace:wgl:X11DRV_WineGL_InitOpenglInfo GL renderer : ATI Radeon X1900 OpenGL Engine. trace:wgl:X11DRV_WineGL_InitOpenglInfo GLX version : 1.2. trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX version : 1.2. trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX vendor: : SGI. trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX version : 1.2. trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX vendor: : SGI. trace:wgl:X11DRV_WineGL_InitOpenglInfo Direct rendering enabled: True ^Cfixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c000013a err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. err:module:LdrInitializeThunk "opengl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\Users\julian\Desktop\Lesson02\Lesson2.exe" failed, status c0000142
MacPro:wine-0.9.56 julian$ DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib WINEDEBUG=+relay ./wine ../Lesson02/Lesson2.exe trace:relay:load_list L"RelayExclude" = L"ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98" trace:relay:load_list L"RelayFromExclude" = L"winex11.drv;user32;gdi32;advapi32;kernel32" 0024:Call KERNEL32.__wine_kernel_init() ret=7bc3c4e7 0024:Call PE DLL (proc=0x60792330,module=0x60760000 L"advapi32.dll",reason=WINE_PREATTACH,res=0x0) 0024:Ret PE DLL (proc=0x60792330,module=0x60760000 L"advapi32.dll",reason=WINE_PREATTACH,res=0x0) retval=1 0024:Call PE DLL (proc=0x61ccb630,module=0x61c60000 L"gdi32.dll",reason=WINE_PREATTACH,res=0x0) 0024:Ret PE DLL (proc=0x61ccb630,module=0x61c60000 L"gdi32.dll",reason=WINE_PREATTACH,res=0x0) retval=1 0024:Call PE DLL (proc=0x61b8be10,module=0x61ad0000 L"user32.dll",reason=WINE_PREATTACH,res=0x0) 0024:Ret PE DLL (proc=0x61b8be10,module=0x61ad0000 L"user32.dll",reason=WINE_PREATTACH,res=0x0) retval=1 0024:Call PE DLL (proc=0x6035c250,module=0x60310000 L"opengl32.dll",reason=WINE_PREATTACH,res=0x0) 0024:Ret PE DLL (proc=0x6035c250,module=0x60310000 L"opengl32.dll",reason=WINE_PREATTACH,res=0x0) retval=1 0024:Call PE DLL (proc=0x7bc6d7a0,module=0x7bc10000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Ret PE DLL (proc=0x7bc6d7a0,module=0x7bc10000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0024:Call PE DLL (proc=0x7b895c60,module=0x7b810000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Ret PE DLL (proc=0x7b895c60,module=0x7b810000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0024:Call PE DLL (proc=0x60792330,module=0x60760000 L"advapi32.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Ret PE DLL (proc=0x60792330,module=0x60760000 L"advapi32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0024:Call PE DLL (proc=0x61ccb630,module=0x61c60000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Ret PE DLL (proc=0x61ccb630,module=0x61c60000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0024:Call PE DLL (proc=0x61b8be10,module=0x61ad0000 L"user32.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Call PE DLL (proc=0x61e88c80,module=0x61e20000 L"winex11.drv",reason=PROCESS_ATTACH,res=0x0) ^C0024:exception in PE entry point (proc=0x61e88c80,module=0x61e20000,reason=PROCESS_ATTACH,res=0x0) 0024:Ret PE DLL (proc=0x61e88c80,module=0x61e20000 L"winex11.drv",reason=PROCESS_ATTACH,res=0x0) retval=1 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c000013a 0024:Ret PE DLL (proc=0x61b8be10,module=0x61ad0000 L"user32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0024:Call PE DLL (proc=0x6035c250,module=0x60310000 L"opengl32.dll",reason=PROCESS_ATTACH,res=0x1) 0024:Call KERNEL32.DisableThreadLibraryCalls(60310000) ret=6035ac0e 0024:Ret KERNEL32.DisableThreadLibraryCalls() retval=00000001 ret=6035ac0e 0024:Call user32.GetDesktopWindow() ret=6035ac24 0024:Call PE DLL (proc=0x61e88c80,module=0x61e20000 L"winex11.drv",reason=PROCESS_ATTACH,res=0x0) 0024:exception in PE entry point (proc=0x61e88c80,module=0x61e20000,reason=PROCESS_ATTACH,res=0x0) 0024:Ret PE DLL (proc=0x61e88c80,module=0x61e20000 L"winex11.drv",reason=PROCESS_ATTACH,res=0x0) retval=1 0024:Ret user32.GetDesktopWindow() retval=00010020 ret=6035ac24 0024:Call KERNEL32.GetModuleHandleA(6036d54e "winex11.drv") ret=6035ac32 0024:Ret KERNEL32.GetModuleHandleA() retval=00000000 ret=6035ac32 0024:Call KERNEL32.GetModuleHandleA(6036d55a "gdi32.dll") ret=6035ac45 0024:Ret KERNEL32.GetModuleHandleA() retval=61c60000 ret=6035ac45 err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. 0024:Ret PE DLL (proc=0x6035c250,module=0x60310000 L"opengl32.dll",reason=PROCESS_ATTACH,res=0x1) retval=0 err:module:LdrInitializeThunk "opengl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\Users\julian\Desktop\Lesson02\Lesson2.exe" failed, status c0000142
http://bugs.winehq.org/show_bug.cgi?id=10184
Scott headrush13@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |headrush13@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #29 from Roderick Colenbrander thunderbird2k@gmx.net 2008-02-25 12:54:14 --- The log clearly indicates that winex11.drv can't be loaded (the handle to it is 0). Make sure winex11.drv was built correctly.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #30 from Roderick Colenbrander thunderbird2k@gmx.net 2008-02-26 07:02:45 --- Second I believe that apple doesn't advertise GLX_SGIX_fbconfig which wine needs. You should force that check to pass inside dlls/winex11.drv/opengl.c E.g.: } else if(glxRequireExtension("GLX_SGIX_fbconfig")) { -> } else if(1 || glxRequireExtension("GLX_SGIX_fbconfig")) {
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #31 from Julian M. mayer.julian@googlemail.com 2008-02-26 12:21:10 ---
The log clearly indicates that winex11.drv can't be loaded (the handle to it is 0). Make sure winex11.drv was built correctly.
i think it is built correctly, non-opengl apps are displayed fine. look at bug 7915 to see how well the same binary comes with "make test"
also please note the message about the X11DRV or GDI32 not loaded appears only after i interrupt the process using Control-C because nothing happens even after a few minutes....look for "^C" in the log i posted.
Second I believe that apple doesn't advertise GLX_SGIX_fbconfig which wine needs.
i think it is advertised just fine, according to glxinfo it is listed in the server and client glx extensions.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #32 from Roderick Colenbrander thunderbird2k@gmx.net 2008-02-26 13:43:58 --- Initialisation of OpenGL was one of the first things which we did in Wine (since this week this has changed). It sounds like it is ending up in an endless loop or so, I can't say why. You would have to analyse the code.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #33 from Julian M. mayer.julian@googlemail.com 2008-02-26 17:10:30 --- ok i sampled it to see where it hangs:
Sampling process 1038 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling wine (pid 1038) every 1 millisecond Call graph: 2545 Thread_2503 2545 start_process 2545 LdrInitializeThunk 2545 process_attach 2545 process_attach 2545 process_attach 2545 process_attach 2545 MODULE_InitDLL 2545 call_dll_entry_point 2545 __wine_spec_dll_entry 2545 DllMain 2545 CLASS_RegisterBuiltinClasses 2545 register_builtin 2545 LoadCursorA 2545 LoadImageA 2545 LoadImageW 2545 CURSORICON_Load 2545 CreateIconFromResourceEx 2545 CreateDCW 2545 DRIVER_load_driver 2545 LoadLibraryA 2545 LoadLibraryExA 2545 LoadLibraryExW 2545 load_library 2545 LdrLoadDll 2545 process_attach 2545 MODULE_InitDLL 2545 call_dll_entry_point 2545 __wine_spec_dll_entry 2545 DllMain 2545 X11DRV_setup_opengl_visual 2545 has_opengl 2545 MakeContextCurrent 2545 SendMakeCurrentRequest 2545 _XLockDisplay 2545 pthread_mutex_lock
2545 semaphore_wait_signal_trap
2545 semaphore_wait_signal_trap 2545 Thread_2603 2545 thread_start 2545 _pthread_start 2545 glvmDoWork 2545 pthread_cond_wait$UNIX2003 2545 __semwait_signal 2545 __semwait_signal
Total number in stack (recursive counted multiple, when >=5): 5 process_attach
Sort by top of stack, same collapsed (when >= 5): __semwait_signal 2545 semaphore_wait_signal_trap 2545 Sample analysis of process 1038 written to file /dev/stdout
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #34 from Lei Zhang thestig@google.com 2008-02-26 17:18:51 --- Please -attach- long outputs. Otherwise it's unreadable.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2008-02-27 03:33:59 --- There's a deadlock with the display lock somewhere in the OpenGL lib. That's an Apple bug.
http://bugs.winehq.org/show_bug.cgi?id=10184
Michał Majchrowicz mmajchrowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mmajchrowicz@gmail.com
--- Comment #36 from Michał Majchrowicz mmajchrowicz@gmail.com 2008-03-02 18:15:30 --- Is it reported to apple/Xquartz project? Is it possible to patch wine/Xquartz to deal with this issue(as a temporary solution till apple fix it)?
http://bugs.winehq.org/show_bug.cgi?id=10184
Bajer Michael eisman@inode.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eisman@inode.at
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #37 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-04 17:22:22 --- A different X11 distribution could help. For instance Codeweavers is shipping their own Xorg version for this reason. Apparently they don't have the issue.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #38 from Julian M. mayer.julian@googlemail.com 2008-03-04 18:21:32 ---
Is it reported to apple/Xquartz project?
A different X11 distribution could help.
i think we should report this bug to apple too, they fixed the last one (BadValue) and should fix this one too (the deadlock). anyone got more details or is willing to do this?
from looking at http://wiki.winehq.org/MacOSX/FAQs i get the impression this is the main issue holding back official winehq mac binaries, so we should either lobby apple into fixing this ASAP or bundle our release with an own X-server build like codeweavers do.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #39 from Michał Majchrowicz mmajchrowicz@gmail.com 2008-03-05 08:12:01 --- I have reported this to Xquartz. http://trac.macosforge.org/projects/xquartz/ticket/74 For now it was only assigned, no response. Since compiling your own X server helps can someone post the instructions to manually compile and set up your own x serwer with wine. It would be good if you could just keep this in one folder in wine directory (xorg i.e.?). This would allow the coexistence of both servers(apple's and wine's) at the same time. Sorry if it is a lame question but I am not familiar with all correlation that wine has with X server on MacOSX.
http://bugs.winehq.org/show_bug.cgi?id=10184
Björn Thiel me@spacecow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |me@spacecow.de
--- Comment #40 from Björn Thiel me@spacecow.de 2008-03-06 03:30:24 --- Maybe it is already know, but I didn't find this solution on winehq. It is possible to circumvent this problem by setting LIBGL_ALWAYS_INDIRECT=1. But I beleave this would diminish performance, and maybe some D3D Features debeind on Direct Rendering. This is no real Solution but a dirty way around although it is possible to play D3D games like NWN1 on e.g. a MacBook.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #41 from Michał Majchrowicz mmajchrowicz@gmail.com 2008-03-07 03:05:28 --- On my machine with Xquartz 2.1.4 adding LIBGL_ALWAYS_INDIRECT=1 doesn't help to even run winecfg not mentioning games :)
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #42 from Julian M. mayer.julian@googlemail.com 2008-03-08 08:57:59 --- retesting with 0.9.57 indicates that LIBGL_ALWAYS_INDIRECT=1 doesn't change a thing. maybe it helped with some of the earlier blockers, but it doesn't help with the deadlock with Xquartz 2.1.
http://bugs.winehq.org/show_bug.cgi?id=10184
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID
--- Comment #43 from Roderick Colenbrander thunderbird2k@gmx.net 2008-03-10 14:59:49 --- As was indicated the main blocker is a bug in the GLX implementation shipped with Apple's X11 implementation. A different X11 implementation can work (Codeweavers is doing exactly that for Crossover). The bug isn't something in Wine, so I'm closing this one.
http://bugs.winehq.org/show_bug.cgi?id=10184
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #44 from Austin English austinenglish@gmail.com 2008-10-13 14:38:06 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #45 from Julian M. mayer.julian@googlemail.com 2008-10-13 18:06:42 --- this is closed in upstream anyway, the X11 update in 10.5.5. makes opengl work.
http://bugs.winehq.org/show_bug.cgi?id=10184
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|Macintosh |PC
http://bugs.winehq.org/show_bug.cgi?id=10184
Laurent Giroud bugs.winehq.org@niaow.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.winehq.org@niaow.com
--- Comment #46 from Laurent Giroud bugs.winehq.org@niaow.com 2009-05-10 16:29:20 --- Hi, I am surprised to see this bug closed. I do have OS X 10.5.6 with xquartz 2.1.5 and I definitely get the X11 error message when trying to launch an OpenGL windows application:
X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x44 Serial number of failed request: 478 Current serial number in output stream: 478
XQuartz version string: Xquartz 2.1.5 - (xorg-server 1.3.0-apple22) (2.1.5)
Apple says this is fixed, but I guess they are not to be trusted on that one ?
http://bugs.winehq.org/show_bug.cgi?id=10184
Calvin Loncaric marvinx03@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marvinx03@gmail.com
--- Comment #47 from Calvin Loncaric marvinx03@gmail.com 2009-05-10 17:55:15 --- (In reply to comment #46)
Hi, I am surprised to see this bug closed. I do have OS X 10.5.6 with xquartz 2.1.5 and I definitely get the X11 error message when trying to launch an OpenGL windows application:
...
Apple says this is fixed, but I guess they are not to be trusted on that one ?
While I am by no means an expert, what little I know of this issue suggests that this is an XQuartz problem, not a Wine problem. There is a new version of XQuartz (2.3.3) that looks like it might have better support, but it won't be installable until Apple releases the update to OS X 10.5.7: http://xquartz.macosforge.org/trac/wiki
I'm running on 10.5.6 and XQuartz 2.3.3 release candidate 5 (http://static.macosforge.org/xquartz/downloads/X11-2.3.3_rc5.dmg) but I'm not seeing any improvement, though. In fact, the XQuartz issue tracker still lists this as an existing problem: http://xquartz.macosforge.org/trac/ticket/122
So it looks like us Apple users will still be living without OpenGL for a while. :(
http://bugs.winehq.org/show_bug.cgi?id=10184
--- Comment #48 from Scott headrush13@gmail.com 2009-05-10 18:02:57 --- There is no technical reason for XQuartz 2.3.3 requirement for 10.5.7. The devs added it because 10.5.7 is imminent and XQuartz must be re-installed after every OS update, so this would cause less users problems.
I have removed the requirement in the installer and installed XQuartz-2.3.3 with 10.5.6 and the linking issues are gone.
Wine is now working terrific with OpenGL. (Although I haven't got full screen working yet, but that is a different issue.)
http://bugs.winehq.org/show_bug.cgi?id=10184
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.5 |Mac OS X
-
wine-bugs＠winehq.org