Re: X11 OpenGL and Wine
Re: X11 OpenGL and Wine
- Subject: Re: X11 OpenGL and Wine
- From: Ben Byer <email@hidden>
- Date: Mon, 12 Nov 2007 01:27:12 -0800
On Nov 11, 2007, at 5:47 AM, email@hidden wrote:
Realized i sent this to Ryan only by accident.. sorry about that..
But I've submitted a bug report about this as well - see #5592835.
But basically: When compiling Wine (Or Darwine with an updated
version of
Wine like i usually do), it Can't find -lGL (and as a result, OpenGL
support) without using DYLD_FALLBACK and the LDFLAGS. Also, for me at
least, without symlinking /S/L/Frameworks/OpenGL.framework/Headers to
/usr/X11/lib/GL, it doesn't find GL/gl.h, GL/glx.h, GL/glext.h, and
GL/glu.h when doing ./configure.
Hm. I just downloaded and built wine straight out of git. Not that
it worked, but it built. :)
Check config.log to figure out exactly what's going on.
With no environment variables set:
$ ./configure
[...]
checking for -lX11... libX11.6.dylib
checking for -lXext... libXext.6.dylib
checking for X11/Xlib.h... yes
checking for X11/XKBlib.h... yes
checking for X11/Xutil.h... yes
checking for X11/Xcursor/Xcursor.h... yes
[...]
checking for -lXinerama... libXinerama.1.dylib
checking for -lXcomposite... libXcomposite.1.dylib
checking for GL/gl.h... yes
checking for GL/glx.h... yes
checking for GL/glext.h... yes
checking for GL/glu.h... yes
checking for up-to-date OpenGL version... yes
checking for -lGL... not found
checking for gluLookAt in -lGLU... yes
[...]
Odd. Let's look at config.log. The "not found" is because of this:
configure:10361: checking for up-to-date OpenGL version
configure:10387: gcc -c -g -O2 -I/usr/X11/include conftest.c >&5
configure:10393: $? = 0
configure:10408: result: yes
configure:10413: checking for -lGL
configure:10448: gcc -o conftest -g -O2 -I/usr/X11/include
conftest.c -lGL -L/usr/X11/lib -R/usr/X11/lib -l
Xext -lX11 -lm >&5
ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
collect2: ld returned 1 exit status
Because that program failed to link, it thinks the library is
unusable. So, adding the LDFLAGS makes it "see" that file.
(sorry for munging the order here:)
Ryan wrote:
I've been using that DYLD_FALLBACK_LIBRARY_PATH since I saw it used by
the chap maintaining the Macports Wine port. It also seemed to be
supported by the section of the page at [...] from which I
concluded /usr/X11/lib wasn't part of the standard linkersearch path.
I was a bit too harsh, there. Yes, it's fully supported, but usually
people use it to accomplish dirty hacks.
<rant>For example, it's the reason that Gimp.app 2.2 doesn't work on
Leopard -- they bundle a copy of all of their dylibs inside the app
bundle, which is super convenient. The problem is that they then have
to use the DYLD_xxx variables to point the linker inside the app
bundle, which then means that those libraries override newer versions
shipped with Leopard. This makes some of the newer libraries in
Leopard that weren't overridden freak out, because those newer
libraries depend on other newer libraries which DO get overridden by
the Gimp.app libraries. It's very confusing for everyone.</rant>
(In this case, though, it may be the correct way to handle this.)
Back to Zach's message:
And even after that, when running a program, with or without LDFLAGS
and
DYLD_FALLBACK, it doesn't find functions needed -
X11DRV_wglGetProcAddress
and X11DRV_ChoosePixelFormat. Neither showed up when i did nm
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/
libGL.dylib
so is it just a matter of the functions not being implemented?
Refer back to my earlier message about OpenGL.framework/libGL.dylib
vs. /usr/X11/lib/libGL.dylib. Take, for instance, glGetProcAddress.
Refer to this code:
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/winex11.drv/opengl.c;h=c510a3b17b5d42fadb5fc0905696f0f9fe4e331a;hb=HEAD#l370
It's trying to dlopen "libGL.dylib" -- which it only finds with the
DYLD_FALLBACK_LIBRARY_PATH. Once it opens /usr/X11/lib/libGL.dylib,
dyld then opens the OpenGL.framework dylib as a dependency, and what I
think is happening is that when it goes to get the address of GL
symbols, it's getting them from the OpenGL.framework instead of the
X11 libGL.dylib.
If you can follow all of that, you can have my job. I'm punting this
to the linker folks :/
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden