when I run wine 1.1.30 or 1.0.1, I encounter the following error:

Both binary version and compile from source code are same.
the OS is Ubuntu 9.04 desktop.
I search on google, it seems I need install opengl libarry before compile it, but I don't know how can I install the spoken libarry.
I am a new hand on Ubuntu, Could someone help me?

I really doubt that binary version is the same. You probably ran your self compiled version.

Make sure you removed what you compiled first (sudo make uninstall). Then follow directions to install new Wine version: http://www.winehq.org/download/deb

thank vitamin for your advice, it worked, but now I run into another error:

I search on internet, some people meet the same situation, but sometimes it can still run, but my application prompt the before sentence then abort.
could Vitamin or someone give I a clue.

What does 'which wine' say?

$ which wine
/usr/bin/wine

Reinstall Wine. Make sure you have Linux video drivers installed properly. If you on 64-bit distro make sure you also install 32-bit driver libraries (might be a separate package / option).

I'm getting this same problem in OS 10.6. Any suggestions?

when you did a ./configure did the result say OpenGl wouldn't be available? might have compiled it wrong.

also on some machines you need to set a variable for it to find things right for X11.



launching it that way can fix if it can't find the proper files.

I installed wine-devel from Macports, so most of the setup/configuration was automated. I'm not actually sure where the ./configure sits (I found the wine directory). I'm trying to play Heroes of Might and Magic V, which I was able to install, but it crashes when starting the program:

err:wgl:opengl_error No OpenGL support compiled in.
err:d3d_caps:WineD3D_CreateFakeGLContext Can't find a suitable iPixelFormat.
err:d3d:InitAdapters Failed to get a gl context for default adapter
err:d3d:WineDirect3DCreate Direct3D9 is not available without opengl

I've looked around a bit, and it seems like Linux users get around this by installing 32-bit drivers? I can't seem to find the OS X versions of those, unfortunately.

zealite wrote:
doh123 had the correct answer for this problem but you will have to
input the line in the same terminal session that you use to build wine.

James McKenzie

Running the program with doh123's code failed to fix the problem. I'm still getting the same error.

because Macports compiled it wrong on your machine... it does that. Your better off building it yourself from source.

If you want to use Macports, do the follwoing in the same session you then afterwards use macports to get wine on...



If you've done those 4 lines, in theory Macports should install Wine correctly, but you may still have to do what i said earlier for it to find it on launch.

So... None of this really solved the problem. I also tried compiling the code myself, and (after working out the hiccups with that) I get the same error.

did you remove X11 off your system? or did you (or Macports automatically) try to change out x.org files? Does your X11 still function correctly?

open up Terminal and type in...



if X11.app fires up right, and you get a window showing colored gears spinning... then your X11 and OpenGL are working fine.

if they are.. compiling it right and setting dyld_fallback should get it to work, so not sure what else to tell ya.

I'm the maintainer of wine in MacPorts, trying to figure out how to solve this problem. Any help would be appreciated, including a reproduction recipe or a link to a Windows program I could install to see this error.



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:





This is not necessary in MacPorts because /opt/local/bin/wine is actually a shell script with the following contents:



The actual wine executable has been moved to /opt/local/libexec/wine/wine. The fallback library path used to also contain the system's X11 library directory (/usr/X11R6/lib on Tiger and older; /usr/X11/lib on Leopard and newer) but this was removed in r50572 because MacPorts now uses its own copy of X11, not the system's, for reasons explained in our FAQ.



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 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.



MacPorts does not modify (or use) the system's X11; MacPorts shouldn't be modifying any part of Mac OS X, in fact; the whole point of MacPorts is to be self-contained. /usr/X11/bin/glxgears (which uses the system's X11 libraries) and /opt/local/bin/glxgears (which uses MacPorts') both work fine on my system.

I more or less gave up on this, but seeing as there was some new information posted, I suppose I should comment on it.

doh123, the spinning gears did, in fact, show up.

ryandesign, is there anything I can do to help?

Can you tell me a command I can type on my system to produce this error message?

On mine, it occurs when I try to run HMM5. The autoplay splash screen shows up fine, I click to run the program, and it crashes with that error message. Presumably, there is an intro cinematic that causes the crash, though I never see it.

ryandesign wrote:
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.

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.)
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

On Dec 12, 2009, at 6:10 PM, James McKenzie wrote:

James, one point: MacPorts X11 *IS* Xquartz. Jeremy Huddleston from UC Berkeley and Apple is the Xquartz maintainer, and the version of X11 in MacPorts is his baby too. Grep for "jeremyhu" in the MacPort's x11 directory Portfile files. It's all the same code.

Generally source changes shake down to MacPorts (or Xquartz) devel versions, then Xquartz alphas or betas, then Xquartz releases and finally straight from Apple after QA. It's all the same code, with the same maintainer, and the multiple entry points actually helps find bugs instead of hurting the development process. The only thing lost is disk space, and using something like MacPorts or Xquartz packages allows updates without breaking your mainline distribution.

Fink's X11, last time I checked, was an entirely different beast, and one of the main reasons I steer clear of Fink. These days I steer clear of MacPorts and homebrew too, but using X11 from MacPorts is just fine and does have some advantages.

-ryan

I can at least confirm, that for *me* the last couple of releases did build fine on MacPorts in 32bit. It might have been that in the chaos after the Snow Leopard release builds were made in 64bit.
But today with a clean Snow Leopard and a clean MacPorts (clean meaning, no things set in the MacPorts files that might mess things up) Wine does build fine.

ryan woodsmall wrote:
Thank you for the clarification. For folks like me, who use Fink, we
should use the XQuartz releases then. For the MacPorts users, they have
the choice of either package.

Good to know information as I made a statement today before reading this.

Go on vakay for a week and see what happens....

James McKenzie