I don't believe this is anything to do with GLFW.

If you have zero-link turned on, turn it off, just in case.

Remember that you can't make OpenGL calls until after you have an OpenGL context (glfwOpenWindow, probably).

Now I get a corrupt stack error.

And this after disabling zero-linking:

And this after putting in a dylib version of glfw:

What on OSX is going on!

For the first error, Google came up with this (first result): http://lists.apple.com/archives/xcode-us...00378.html
It looks like you have copied libglfw.a and messed up its created/modified dates. Running ranlib (as suggested by Xcode) should sort that out. Since the library has not been linking, this is probably the cause of all your problems up until now.

Regarding your new error (with the dylib), have you added the dylib to your "copy files" build phase? The path @executable_path/libglfw.dylib looks wrong anyway - the dylib should go in the Frameworks directory inside your app bundle, so it should be loaded from @executable_path/../Frameworks/libglfw.dylib I think.

Thanks, that solved the linking problem with libglfw.a

Now I have this:

which opens auto maticly even in release mode.

Also, I looked into the app bundle and there is no frameworks folder.

Are you sure no one has a sample .xcodeproject for me to try because this is driving me up the wall at the lack of online documentation for glfw and xcode.

Yes, this is a double post due to the fact that no one has answered in a while and now I have a new problem, when I use pkgconfig to compile I get this:

The above message most likely means that the linker isn't aware of those functions at link time, so it can't resolve the symbols. Check the command-line parameters to gcc/ld and verify that OpenGL.framework and glfw are present. Ideally, paste the entire command line that's being used.

Yep, as suspected, OpenGL.framework is missing from your compiler parameters. It looks like a number of other things are broken, too:

• You're trying to call pkg-config, which doesn't appear to exist, or at least isn't in your $PATH. It's warning you about it with "tcsh: pkg-config: Command not found.".
• myprog.c doesn't exist in the first call.
• You'll need to add "-framework OpenGL" and either "-lglfw" or the path to libglfw.a, depending on whether it's in your library search paths or not. Maybe this is what the output of pkg-config is expected to be?
  

So, what you'd want would look something like this:

Thanks, that worked!
I had to change it to :

Now its telling me to build an .app wrapper.
Fortunately that message is from glfw.
How do I build an .app wrapper?
(google keeps giving results for java)

Entire message

Glad to hear that's working for you!

The most basic .app wrapper would look be a directory structure that looks like this, where MyProgram is your executable: MyProgram.app/Contents/MacOS/MyProgram

To be a little bit more correct about it, you'd want to put two more files in Contents: Info.plist and PkgInfo. This page can tell you more about those two files: http://developer.apple.com/documentation...2094-98415

You'd also most likely want a "Resources" directory sibling to MacOS for storing external assets your application uses. Applications on Mac OS X are supposed to be self-contained, and this is the standard place to put ancillary files.

So, I built a .app wrapper and I get a EXC_BAD_ACCESS error in the crash log.

I'm not really much of a Mac guy(can you tell), I just hate Microsoft .
I've only did this stuff for a year and haven't learned all the error codes and the like.
Forgot:
my O3D.app is setup like:
Contents
-PkgInfo
-Info.plist
-Frameworks
->OpenGL.framework
->AGL.framework
->Carbon.framework
-MacOs
->myProgram
-Resources

Again, there's too little information here, but the most likely reason to crash during glClearColor is that you cannot call OpenGL functions before you have a window.

However the window is opening as, if it didn't, an error from my code would go to the console.
I believe all my errors may come from linking to the frameworks.

You've called glClearColor successfully, it has a sane address in the correct dylib. This is *not* a linking issue. Check that your call to glClearColor comes *after* glfwOpenWindow.

Alternatively, put
just before the glClearColor call that's crashing. If that abort gets hit, you haven't called glfwOpenWindow [successfully].