MAC OS X compile -> 'OpenGL development headers not found
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
MAC OS X compile -> 'OpenGL development headers not found
Hey everyone,
I want to compile and start using Wine on my Mac, but I'm getting the following message from ./configure:
configure: WARNING: OpenGL development headers not found.
OpenGL and Direct3D won't be supported.
Since I want OpenGL and Direct3D working, this is a bit of a problem. My system is not configured funny or anything. It is a clean system running Mac OS X Snow Leopard with a freshly installed copy of XCode 3.2... I didn't fiddle with environment variables or anything else, so my setup is quite ordinary.
Is it Snow Leopard or XCode 3.2 at fault? I checked the FAQ and various notes on the site, I also tried the google custom search on here, but no solutions .
Does anyone know what might be causing this?
Thanks,
Raz.
I want to compile and start using Wine on my Mac, but I'm getting the following message from ./configure:
configure: WARNING: OpenGL development headers not found.
OpenGL and Direct3D won't be supported.
Since I want OpenGL and Direct3D working, this is a bit of a problem. My system is not configured funny or anything. It is a clean system running Mac OS X Snow Leopard with a freshly installed copy of XCode 3.2... I didn't fiddle with environment variables or anything else, so my setup is quite ordinary.
Is it Snow Leopard or XCode 3.2 at fault? I checked the FAQ and various notes on the site, I also tried the google custom search on here, but no solutions .
Does anyone know what might be causing this?
Thanks,
Raz.
MAC OS X compile -> 'OpenGL development headers not found
On Sep 3, 2009, at 12:05 AM, raziel2001au wrote:
enough that you probably won't have a ton of luck. I have 1.1.29
working on my MacBook with Snow Leopard, with OpenGL working.
Direct3D is another matter - haven't had enough time to work that out
yet. I have an Intel X3100 graphics card; the newer Nvidia-based
machines might fare better.
Are you setting any LDFLAGS, or explicitly setting CC/CXX? To force
32-bit, I'm using:
gcc -arch i386 -m32
for my compiler flags; to set a few linker flags, I'm using:
-framework CoreServices -lz -L/usr/X11/lib -lGL -lGLU
YMMV, of course. OpenGL shouldn't be an issue, though.
ryan woodsmall
[email protected]
"Be well, do good work, and keep in touch." - Garrison Keillor
There are a lot of prereqs to compiling on OS X. Snow Leopard is newI want to compile and start using Wine on my Mac, but I'm getting
the following message from ./configure:
configure: WARNING: OpenGL development headers not found.
OpenGL and Direct3D won't be supported.
Since I want OpenGL and Direct3D working, this is a bit of a
problem. My system is not configured funny or anything. It is a
clean system running Mac OS X Snow Leopard with a freshly installed
copy of XCode 3.2... I didn't fiddle with environment variables or
anything else, so my setup is quite ordinary.
Is it Snow Leopard or XCode 3.2 at fault? I checked the FAQ and
various notes on the site, I also tried the google custom search on
here, but no solutions .
Does anyone know what might be causing this?
enough that you probably won't have a ton of luck. I have 1.1.29
working on my MacBook with Snow Leopard, with OpenGL working.
Direct3D is another matter - haven't had enough time to work that out
yet. I have an Intel X3100 graphics card; the newer Nvidia-based
machines might fare better.
Are you setting any LDFLAGS, or explicitly setting CC/CXX? To force
32-bit, I'm using:
gcc -arch i386 -m32
for my compiler flags; to set a few linker flags, I'm using:
-framework CoreServices -lz -L/usr/X11/lib -lGL -lGLU
YMMV, of course. OpenGL shouldn't be an issue, though.
ryan woodsmall
[email protected]
"Be well, do good work, and keep in touch." - Garrison Keillor
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
Even with:
./configure LDFLAGS='-framework CoreServices -lz -L/usr/X11/lib -lGL -lGLU' CXX='gcc -arch i386 -m32'
I'm still getting the OpenGL development headers missing message, which is annoying. I would have thought it would be a bit more straight-forward since there are already mac specific things inside the configure script, plus darwine didn't seem to do anything overly specific, though its opengl admittedly was just as broken . This must be an XCode 3.2 thing.
./configure LDFLAGS='-framework CoreServices -lz -L/usr/X11/lib -lGL -lGLU' CXX='gcc -arch i386 -m32'
I'm still getting the OpenGL development headers missing message, which is annoying. I would have thought it would be a bit more straight-forward since there are already mac specific things inside the configure script, plus darwine didn't seem to do anything overly specific, though its opengl admittedly was just as broken . This must be an XCode 3.2 thing.
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
Just tried the compile step... now that's failing on riched20.dll.so, which used to work before I altered the compiler/linker flags, of course then OpenGL is broken. So I'm back to square 1.
Perhaps I should just stick to prebuilt binaries... although the newest binaries I could find is 1.1.21. I would have liked to run the latest.
Perhaps I should just stick to prebuilt binaries... although the newest binaries I could find is 1.1.21. I would have liked to run the latest.
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
It's okay, I sorted it all out... this is what I ended up using:
./configure CPPFLAGS='-I/usr/X11/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib'
Seems to build successfully now, I'll test it later at some point, but I thought I would at least pop this info in here for anyone who might be interested. I'm not entirely sure if the LIBS part is actually necessary, but I don't imagine it can do any real harm.
./configure CPPFLAGS='-I/usr/X11/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib'
Seems to build successfully now, I'll test it later at some point, but I thought I would at least pop this info in here for anyone who might be interested. I'm not entirely sure if the LIBS part is actually necessary, but I don't imagine it can do any real harm.
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
Well, I just tried the resulting compiled file... and, guess what, it doesn't work . It compiles fine, but if you try and run an OpenGL based application, you just get this:
err:wgl:has_opengl Failed to load libGL: dlopen(libGL.1.dylib, 266): image not found
err:wgl:has_opengl OpenGL support is disabled.
Picture me with a really confused look on my face, I've been at it for about 2 days now, I still can't get a basic compile working with 3D acceleration.
err:wgl:has_opengl Failed to load libGL: dlopen(libGL.1.dylib, 266): image not found
err:wgl:has_opengl OpenGL support is disabled.
Picture me with a really confused look on my face, I've been at it for about 2 days now, I still can't get a basic compile working with 3D acceleration.
I can confirm this is a Snow Leopard problem...
on my main machine i always used to make Wine builds... it used to work fine. I got this same error in Snow Leopard now using standard configure...
for testing i went back and recompiled the same exact 1.1.28 that worked fine before I upgraded and it has the same exact error now and no longer works....
I compiled 1.1.29 on a 10.5 leopard box and it doesn't give this error.
This is definitely a Snow Leopard related problem.. and we need to find a fix, I don't wanna have to stick back with 1.1.28 for too long
I am making a tool for making Mac ports of software based on Wine, and really don't want to have to go borrow someones Leopard machine every time i want to make a new Wine.bundle to use....
for info, I do make my Wine Bundles very similar to how Darwine scripts did them.. but I haven't scripted it, i just kinda build and install and put them together manually, its not that tough... my builds would work for you I guess, but I kinda customize them a minor to work right in the application I've been working on...
on my main machine i always used to make Wine builds... it used to work fine. I got this same error in Snow Leopard now using standard configure...
for testing i went back and recompiled the same exact 1.1.28 that worked fine before I upgraded and it has the same exact error now and no longer works....
I compiled 1.1.29 on a 10.5 leopard box and it doesn't give this error.
This is definitely a Snow Leopard related problem.. and we need to find a fix, I don't wanna have to stick back with 1.1.28 for too long
I am making a tool for making Mac ports of software based on Wine, and really don't want to have to go borrow someones Leopard machine every time i want to make a new Wine.bundle to use....
for info, I do make my Wine Bundles very similar to how Darwine scripts did them.. but I haven't scripted it, i just kinda build and install and put them together manually, its not that tough... my builds would work for you I guess, but I kinda customize them a minor to work right in the application I've been working on...
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
I see, so it's not just me then... compilation of the OpenGL stuff is definitely broken in Snow Leopard.
I've been stressing over this for the last 2 days with no success. So how about this wonderful idea -> can you report the issue in Bugzilla and I'll just sit back and relax and wait for it to be fixed in 1.1.30 .
I've been stressing over this for the last 2 days with no success. So how about this wonderful idea -> can you report the issue in Bugzilla and I'll just sit back and relax and wait for it to be fixed in 1.1.30 .
I'm trying to work on it and figure out a fix... but..
but.. I've nver really messed with anything 64 bit so.. I was trying to clear up my easier missing files first, like Freetype and such... but I really don't know how to specify to compile the source at 32 bit, it always complies it 64 bit, and Wine errors by not finding the 32 bit libraries.
In the other Snow Leopard related thread, Ryan said to use the flags "gcc -arch i386 -m32" which makes total sense, but I really have no clue how to actually do that... yet.. at least.. so if i can get all the other error messages out of the way so that the OpenGl header one is the only one left on my building... maybe my stubbornness will find a way past that too.
but.. I've nver really messed with anything 64 bit so.. I was trying to clear up my easier missing files first, like Freetype and such... but I really don't know how to specify to compile the source at 32 bit, it always complies it 64 bit, and Wine errors by not finding the 32 bit libraries.
In the other Snow Leopard related thread, Ryan said to use the flags "gcc -arch i386 -m32" which makes total sense, but I really have no clue how to actually do that... yet.. at least.. so if i can get all the other error messages out of the way so that the OpenGl header one is the only one left on my building... maybe my stubbornness will find a way past that too.
MAC OS X compile -> 'OpenGL development headers not found
The flags have to be set in the configure and make portion of the build. I'll look and see if this is an easy fix.I'm trying to work on it and figure out a fix... but..
but.. I've nver really messed with anything 64 bit so.. I was trying to clear up my easier missing files first, like Freetype and such... but I really don't know how to specify to compile the source at 32 bit, it always complies it 64 bit, and Wine errors by not finding the 32 bit libraries.
In the other Snow Leopard related thread, Ryan said to use the flags "gcc -arch i386 -m32" which makes
total sense, but I really have no clue how to actually do that... yet.. at least.. so if i can get all the other
error messages out of the way so that the OpenGl header one is the only one left on my building... maybe
my stubbornness will find a way past that too.
James McKenzie
I just want to add.. i do NOT think its some fundamental change in Snow Leopard, it has to be something Minor...
If i build Wine in Leopard, and manually move it over to my Snow Leopard box, it runs just fine, no problems at all... its only the build that is failing.... so this should be something that can be fixed easy, for those that have a clue how to (not me).
If i build Wine in Leopard, and manually move it over to my Snow Leopard box, it runs just fine, no problems at all... its only the build that is failing.... so this should be something that can be fixed easy, for those that have a clue how to (not me).
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
Agreed, what I am seeing is that it is refusing to use the GL library it should be using, I've posted about this in a separate thread: http://forum.winehq.org/viewtopic.php?t=6044doh123 wrote:I just want to add.. i do NOT think its some fundamental change in Snow Leopard, it has to be something Minor...
If i build Wine in Leopard, and manually move it over to my Snow Leopard box, it runs just fine, no problems at all... its only the build that is failing.... so this should be something that can be fixed easy, for those that have a clue how to (not me).
Strangely I have not run into the 64bit issue people have mentioned - in fact, it looks to me like my compiles are adding -m32 automatically... The only issue I'm seeing is that it *should* be using libGL.dylib, but even if you force it to look into the frameworks folder, it just completely ignores that file and says it doesn't find a library. It does find libGL.1.dylib if you point it to the X11 libraries folder, but that isn't what we want because then you have to manually specify fallback paths for it to find the library at runtime and I'm pretty sure that it won't work in Leopard either...
-
- Level 2
- Posts: 21
- Joined: Wed Sep 02, 2009 11:56 pm
You can *technically* make it work, even Direct3D works for me, but you have to use the DYLD_FALLBACK_LIBRARY_PATH environment variable to get it to find the gl library, rather than it just working automagically. Since I can't rely on a compile like this, I can't really distribute it publicly... which sux.
MAC OS X compile -> 'OpenGL development headers not found
On Sat, Sep 5, 2009 at 10:17, raziel2001au<[email protected]> wrote:
first intel MAcs had 32bit Core Duo CPUs) (It might be that it cause a
different gcc to run (or different code path, not sure how "fat"
binaries / universal applications work..))
Doesn't the CPU in the MacBook affect the default architecture? (TheStrangely I have not run into the 64bit issue people have mentioned - in fact, it looks to me like my compiles are adding -m32 automatically... The only issue I'm seeing is that it *should* be using libGL.dylib, but even if you force it to look into the frameworks folder, it just completely ignores that file and says it doesn't find a library. It does find libGL.1.dylib if you point it to the X11 libraries folder, but that isn't what we want because then you have to manually specify fallback paths for it to find the library at runtime and I'm pretty sure that it won't work in Leopard either...
first intel MAcs had 32bit Core Duo CPUs) (It might be that it cause a
different gcc to run (or different code path, not sure how "fat"
binaries / universal applications work..))
MAC OS X compile -> 'OpenGL development headers not found
On Sep 5, 2009, at 3:38 PM, clone2727 wrote:
lib if you're using Xquartz (http://xquartz.macosforge.org/) on 10.5/
Leopard or the default X11.app in 10.6/Snow Leopard. The X11.app in
10.6 is based on Xquartz, and includes OpenGL bits that are
essentially wrappers around the system OpenGL frameworks.
Please see the MacPorts or Fink package descriptors for Wine. I know
for a fact that the "wine-devel" package in MacPorts is at version
1.1.29 and wraps wine in a script that sets a MacPorts-specific
DYLD_FALLBACK_LIBRARY_PATH.
See http://forum.winehq.org/viewtopic.php?t=6044 for a bit more info.
Would it be possible for folks to pick *one* thread on OS X/Snow
Leopard and stick with it?
ryan woodsmall
[email protected]
You *MUST* set DYLD_FALLBACK_LIBRARY_PATH to include at least /usr/X11/It's not just a Snow Leopard problem; I'm having the same problem in
Leopard 10.5.7 (the failing to load OpenGL). I didn't have a problem
linking with OpenGL, however.
lib if you're using Xquartz (http://xquartz.macosforge.org/) on 10.5/
Leopard or the default X11.app in 10.6/Snow Leopard. The X11.app in
10.6 is based on Xquartz, and includes OpenGL bits that are
essentially wrappers around the system OpenGL frameworks.
Please see the MacPorts or Fink package descriptors for Wine. I know
for a fact that the "wine-devel" package in MacPorts is at version
1.1.29 and wraps wine in a script that sets a MacPorts-specific
DYLD_FALLBACK_LIBRARY_PATH.
See http://forum.winehq.org/viewtopic.php?t=6044 for a bit more info.
Would it be possible for folks to pick *one* thread on OS X/Snow
Leopard and stick with it?
ryan woodsmall
[email protected]
MAC OS X compile -> 'OpenGL development headers not found
On Sep 5, 2009, at 6:33 AM, Gert van den Berg wrote:
Intel Macs had Core Solo/Duo processors which are 32-bit only.
There's also the question of the compiler in use; Snow Leopard comes
with GCC 4.2 and 4.0. GCC 4.2, the Snow Leopard default, appears to
output whatever architecture you're running on; as I'm on 64-bit
capable procs, that's what I'm seeing. GCC 4.0 appears to output the
"base" arch - i.e., 32-bit code that will run on everything.
I only have access to Core 2 Duo machines - one Mac Mini, one MacBook
- both having Intel graphics. information on proc and GCC outputs
below, both showing the default 64-bit output of 4.2 on my Core 2 Duo
machines, and the 4.0 32-bit output on same.
If you want universal/fat binaries, you really have to specify them
via compiler options:
gcc -arch i386 -arch x86_64 ...
ryan woodsmall
[email protected]
Yes Gert, that is likely at least part of the difference. The firstDoesn't the CPU in the MacBook affect the default architecture? (The
first intel MAcs had 32bit Core Duo CPUs) (It might be that it cause a
different gcc to run (or different code path, not sure how "fat"
binaries / universal applications work..))
Intel Macs had Core Solo/Duo processors which are 32-bit only.
There's also the question of the compiler in use; Snow Leopard comes
with GCC 4.2 and 4.0. GCC 4.2, the Snow Leopard default, appears to
output whatever architecture you're running on; as I'm on 64-bit
capable procs, that's what I'm seeing. GCC 4.0 appears to output the
"base" arch - i.e., 32-bit code that will run on everything.
I only have access to Core 2 Duo machines - one Mac Mini, one MacBook
- both having Intel graphics. information on proc and GCC outputs
below, both showing the default 64-bit output of 4.2 on my Core 2 Duo
machines, and the 4.0 32-bit output on same.
If you want universal/fat binaries, you really have to specify them
via compiler options:
gcc -arch i386 -arch x86_64 ...
ryan woodsmall
[email protected]
-
- Level 2
- Posts: 20
- Joined: Tue Feb 24, 2009 9:50 pm
And the actual compiler stuff... -ryan
Code: Select all
$ system_profiler | egrep "(Model|Processor) Name:"
Model Name: MacBook
Processor Name: Intel Core 2 Duo
$ cat > hello.c << "EOF"
> #include <stdio.h>
> int main(void)
> {
> printf("hello.\n");
> return(0);
> }
> EOF
$ gcc-4.2 hello.c -o hello
$ file hello
hello: Mach-O 64-bit executable x86_64
$ gcc-4.0 hello.c -o hello
$ file hello
hello: Mach-O executable i386
$ system_profiler | egrep "(Model|Processor) Name:"
Model Name: Mac mini
Processor Name: Intel Core 2 Duo
$ cat > hello.c << "EOF"
> #include <stdio.h>
> int main(void)
> {
> printf("hello.\n");
> return(0);
> }
> EOF
$ gcc-4.2 hello.c -o hello
$ file hello
hello: Mach-O 64-bit executable x86_64
$ gcc-4.0 hello.c -o hello
$ file hello
hello: Mach-O executable i386