Re: X11 OpenGL and Wine
Re: X11 OpenGL and Wine
- Subject: Re: X11 OpenGL and Wine
- From: email@hidden
- Date: Mon, 12 Nov 2007 05:10:12 -0800 (PST)
>
> 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.
>
Hm, guess the header files not found is just my system being messed up..
good to know at the very least, even if it means i messed up somewhere xD
> (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.)
I think that Crossover Mac does the same thing for OpenGL (packaging
libraries in), which might be why that has OpenGL support whereas
Wine/Darwine doesn't.. Though that doesn't seem to have any problems.
Would this a side result of the linker error or just because they
(possibly) ship with the same library versions to use directly instead of
relying on OS X's version?
>
> 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
>
>
Just to walk myself through it and see if i'm kinda understanding it - i
needed to read it a few times.. It first finds everything properly when
compiling due to DYLD.. being set when compiling, however
/usr/X11/lib/libGL.dylib relies on /S/L/F/OpenGL.framework's version of
libGL.dylib (What's the difference between the two? GLX vs CGL?) and then
it fails because the symbols (or reference to symobls?) are different /
not available?
I'm pretty positive I'm missing a few parts here here - as otherwise just
setting DYLD each time starting wine up would work - but that doesn't.
Anyway this is to confusing for me - especially in the morning, so your
job's safe :P
Thanks for all the help and explanations, cleared some things up.
Hopefully the linker folks will be able to fix this :\
-Zach
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden