Update to 3.0.2

[nkpart]

Currently on Mac OS 10.9 (Mavericks), I get this error when building:

glfw/src/../deps/GL/glext.h:6165:22:
 error: typedef redefinition with different types ('unsigned int' vs 'void *')
typedef unsigned int GLhandleARB;
                     ^
/Applications/Xcode5-DP6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:65:15:
     note: previous definition is here
typedef void *GLhandleARB;

This has been fixed in the 3.0.2 release of GLFW, any chance you could update to it?

[bsl]

It's on my urgent TODO, but my job takes almost all my time. I'll get to it ASAP. Thanks for your patience.

[MaxDaten]

My naive approach to get this binding working with 3.0.2/3.0.3: replace the glfw src folder with the new sources. cabal build completes successfully. But cabal test or other use of this library (e.g. GLFW-b) leads to a nasty bindings-GLFW/dist/build/libHSbindings-GLFW-0.1.0.a: unknown symbol__objc_empty_vtable'`

Im currently investigating this error but I'm stuck.

OS X 10.9 with the new XCode version brings some major changes:

• clang is now the default compiler
• OpenGL 4.1
• new SDK

Some thoughts:

• maybe clang misses some flags used by the ghc/cabal build tools. For example: -nodefaultlibs unused warnings appears in the cabal build log. So maybe clang dyn-links to libs that are not implicitly present in the ghc environment
• ...

[bsl]

I'm not sure about your specific build problem, but I can explain a bit about why I haven't updated bindings-GLFW yet.

GLFW (the C library) uses cmake to build a config.h suitable for your system. We don't want to require users to have cmake to build bindings-GLFW, so we generated config.h files on the three OSes we care about, and select the proper one at build time. But every time a new version of GLFW is released, I need to generate new config.h files, and I don't have Windows or OS X.

In the near future, I'll just ask friends with access to Windows and OS X to generate those files for me so that I can get a new bindings-GLFW out. That may resolve your issues. Sorry for the delay. :(

[MaxDaten]

Hi there,
I can provide those config.h's for OS X and Windows.

Currently I spend serval hours to snipe down this annoying build failure:

My current state:

• cabal test or at least building GLFW-b or cabal repl leads to this failure:

lookupSymbol failed in relocateSection (relocate external)
/Users/jloos/Workspace/hs/bindings-GLFW/dist/build/libHSbindings-GLFW-0.1.1.a: unknown symbol `__objc_empty_vtable'

• __objc_empty_vtable seems part of the libobjc.A.dylib if using gcc with objective-c support instead of clang (I guess). It's part of the Objective-C Runtime
• __objc_empty_vtable is referenced from cocoa_window.o but it's not the only reference to the objc runtime (just the first one in use)

I'm not very familiar with OS X development (especially ObjC) and to the depth of haskell building, but I guess there are problems with the dynamic linking to the ObjC Runtime on the ghc/ghci side. I'm not sure if this is really fixable with project side building flags. I naivly tried -ObjC and -all_load to static linking to the runtime (Apple Developer Reference), without any effect (binary equally).

I will keep trying ;)

Edit: my build log
Edit2: my cabal repl log

[MaxDaten]

quick update: I managed to build the current ghc HEAD with an brew installed gcc48 with an brew ghc-7.6.3 for bootstrapping the build. With this ghc version and with gcc48 I was able to built bindings-GLFW to a usable library. This is now nearly the build environment before 10.9, based on gcc. No real progress so far.

Sadly I wasn't able to build the ghc HEAD with clang, so I can't predict any behavior with ghc-7.8 on OS X 10.9. But I changed the installed snapshot ghc settings to use clang instead of ghc48 (settings located in: /usr/local/lib/ghc-7.7.20131024/settings), and cabal test runs. So good signs ahead ;)

[MaxDaten]

further progress captured here #7 :