[Wine] No opengl support compiled in

[James McKenzie]

ryandesign wrote:
> daniel_zh9 wrote:
>   
>> Code:
>> err:wgl:opengl_error No OpenGL support compiled in.
>>
>>
>>
>>     
>
>
> I'm the maintainer of wine in MacPorts, trying to figure out how to solve this problem (http://trac.macports.org/ticket/22293). Any help would be appreciated, including a reproduction recipe or a link to a Windows program I could install to see this error.
>
>
> doh123 wrote:
>   
>> when you did a ./configure did the result say OpenGl wouldn't be available?  might have compiled it wrong.
>>     
>
>
> On my Snow Leopard 10.6.2 system with Xcode 3.2.1, it seems to find it; wine 1.1.33's configure says:
>
>
> Code:
> configure checking for GL/gl.h... yes
> configure checking for GL/glx.h... yes
> configure checking for GL/glu.h... yes
> configure checking for up-to-date OpenGL version... yes
>
>
>
>   
Good that OpenGL is available.  What version of OpenGL extensions are
supported? 

The key is that Snow Leopard is using a modified version of XQuartz
2.4.0 and thus this would be a good target to build to.  It includes
support for OpenGL extension version 1.3.

>
> doh123 wrote:
>   
>> also on some machines you need to set a variable for it to find things right for X11.
>>
>>
>> Code:
>> DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib" wine program_name.exe
>>
>>
>>     
>
>
> This is not necessary in MacPorts because /opt/local/bin/wine is actually a shell script with the following contents:
>
>
> Code:
> #!/bin/sh
> # $Id$
>
> DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" \
> "/opt/local/libexec/wine/wine" "$@"
>
>   
As a comment here, that means that the X11 libraries are IN
/opt/local/lib not in ANY subdirectory, like /opt/local/lib/X11 or
/opt/local/lib/X11/lib.  Otherwise, the library files WILL NOT be found
(this was a major problem with the Darwine builds based upon Mike
Kronenberg's builds.)
>
> The purpose of having a package management system like MacPorts is to encapsulate a recipe that will result in software being correctly installed on an operating system. (For MacPorts, the target OS is understandably Mac OS X.) It is more efficient for one person (the port maintainer -- me) to figure out how to configure and compile a program than for everyone to have to do it. Therefore I would prefer that we would amend the recipe until it works (please file bug reports (http://guide.macports.org/chunked/project.html#project.tickets) against ports that don't work) rather than throw it out entirely (building from source manually as you suggested).
>
> This will have no effect in MacPorts because it deliberately clears the user's environment, to ensure a consistent experience.
>
> The wine and wine-devel ports in MacPorts are hardwired to build for i386 only, even on Snow Leopard where the default is to build for x86_64. For this to work, all dependencies must either be built for i386 only as well, or built universal for i386 and x86_64. The latter is recommended, and accomplished by using the +universal variant. (universal_archs must also be set to "x86_64 i386" in /opt/local/etc/macports/macports.conf but this is the default on Snow Leopard.) If the user forgets to build dependencies universal, the wine ports detect this and suggest the user do this. If the user would rather build everything for i386 only, this can be done by setting build_arch to i386 in macports.conf.
>
>   
This has been reported several times to NOT WORK.  Users have reported
that Snow Leopard MacPorts builds were built for x86_64 and had to be
rebuilt after the fact to i386. 

Here is something that I would like to comment on:  Maintaining two
versions of a very large package, like X11, is mainly a waste of time
and resources.  There are, currently, no planned updates to X11 by
Apple.  If there is something 'broken' in Apple's X11, then a report
should be filed with XQuartz AND Apple, not building a second version of
the program.  I know that this sounds like a rant, but we, the Apple
community, need to keep Apple on their toes and not go around fixing
their broken 'stuff'. 

And I know that the intent is to make the User Experience better, but we
are hiding serious problems and without reporting them, we are
encouraging Apple to be lazy.  All programs should be built to what
comes out of the box unless the program is unavailable from Apple and
then we should build using Apple's programs (XCode is a good example
when we substitute gcc.)  This is why the Wine project recommends
building Wine from source, and to not use any of the ports, including
MacPorts as the projects tend to break the Wine build in very
interesting ways that we cannot fix nor even begin to attempt to try to fix.

Please do keep in mind that we are not telling the MacPorts project how
to do things, but I have years of experience with coding, testing and
implementation.  The comments above are mine and not the projects but
are based upon years of being here and what is good for the end user.  
Also, look up 'dll hell' to see what can happen when you build to your
own sources and what can happen when users decide NOT to do exactly what
you expect.

James McKenzie