When I tried to install GLFW-b-1.4.8.1 through either Cabal or Stack, it will first install bindings-GLFW-3.1.2.2, but after succesfully doing so it moves on with GLFW-b and I get the following error:

ghc.exe: C:\Users\Paul\AppData\Roaming\cabal\x86_64-windows-ghc-8.0.1\bindings-G
LFW-3.1.2.2-14y8Rlh9wxcHUOlWbio9J9\HSbindings-GLFW-3.1.2.2-14y8Rlh9wxcHUOlWbio9J
9.o: unknown symbol `strdup'

ghc.exe: unable to load package `bindings-GLFW-3.1.2.2'
cabal: Leaving directory 'C:\Users\Paul\AppData\Local\Temp\cabal-tmp-1920\GLFW-b
-1.4.8.1'
Failed to install GLFW-b-1.4.8.1
cabal: Error: some packages failed to install:
GLFW-b-1.4.8.1 failed during the building phase. The exception was:
ExitFailure 1

Since the problem seems to be after the package is installed, this might be a bug in GHC or Cabal. I figured I'd report it here though, as you're probably more qualified to figure it out.

I worked around this by manually installing bindings-GLFW-3.1.2.1 instead of 3.1.2.2, that one works just fine.

Hello, here I am again bothering you all. Hope you are all well.
This time the issue is related to cabal-install v3+ (I use v3.4.0.0). Apparently the new v2-install command style is unable to understand how to install a local package, by default fetching the package via internet from the repository. To have bindings-GLFW working on OpenBSD, I modify the file bindings-GLFW.cabal to have the line containing if os(linux) || os(freebsd) in if os(linux) || os(freebsd) || os(openbsd). This works fine with cabal v1-install, which understands how to install local packages, but I can no longer use this trick with cabal v2-install. I want to use the new v2 style because the v1 is considered deprecated and will be removed soon. But this means, the bindings-GLFW package from the repository has to be already modified to have v2-install working on OpenBSD. Can you apply this patch and add support to bindings-GLFW for OpenBSD? I now use bindings-GLFW v3.3.2.0.
Thank you very much.

I'm unable to compile the bindings on OpenBSD, I modified bindings-GLFW.cabal "adding support" for OpenBSD with this change:

if os(linux) || os(freebsd) || os(openbsd)

When I try to compile these bindings I get this error:

$ runhaskell Setup.hs configure --user --extra-include-dir=/usr/X11R6/include/ --extra-lib-dir=/usr/X11R6/lib/
Configuring bindings-GLFW-3.0.3.3...
$ runhaskell Setup.hs build
Building bindings-GLFW-3.0.3.3...
Preprocessing library bindings-GLFW-3.0.3.3...
[1 of 1] Compiling Bindings.GLFW    ( dist/build/Bindings/GLFW.hs, dist/build/Bindings/GLFW.o ) [flags changed]
In file included from glfw/src/glx_platform.h:37,
                 from glfw/src/x11_platform.h:52,
                 from glfw/src/internal.h:69,
                 from glfw/src/x11_clipboard.c:27:0:
glfw/src/../deps/GL/glxext.h:275:0:
     error: redefinition of typedef 'GLXContextID'
/usr/X11R6/include/GL/glx.h:171:0:
     error: previous declaration of 'GLXContextID' was here
In file included from glfw/src/x11_platform.h:52,
                 from glfw/src/internal.h:69,
                 from glfw/src/x11_clipboard.c:27:0:
glfw/src/glx_platform.h:95:0:
     error: expected specifier-qualifier-list before 'pthread_key_t'

I used ghc 7.6.3p1, bindings-GLFW 3.0.3.3, glfw 3.0.4, OpenBSD 5.6.

Sorry for creating this issue, but I need a place to publicly trac my current informations about this issue.

On a 10.8 -> 10.9 updated OS X building and linking bindings-GLFW runs in the following error:

Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.20 ... linking ... done.
Loading package bindings-GLFW-3.0.3 ... linking ... ghc:
lookupSymbol failed in relocateSection (relocate external)
/Users/jloos/Workspace/hs/bindings-GLFW/dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable'
ghc: unable to load package `bindings-GLFW-3.0.3'

__objc_empty_vtable is part of the Objective-C runtime.
This error is already mentioned in /issues/5 #5 (comment)

It happens with the apple-gcc-4.2.1 and homebrew'ed gcc48

Maybe it is in a way related to the libc++ libstdc++ changes in 10.9 (despite the ObjC relation?) reported in Homebrew/legacy-homebrew#23687 or maybe completely an ghc-7.6.3 linking issue. Linking will be improved in ghc 7.8, I tried the ghc HEAD and linking to bindings-GLFW works, but ghc 7.8 runs a way better with clang at all, maybe 'just' a side effect.

After some further investigation, I will report this issue on the ghc trac.

@bsl dont bother yourself with this issue to much, it's more ore less just for me and more an investigation tracing.

Hello,

Running into the following on OSX Yosemite:

timo@Timothees-MBP ~/g/nehe-tuts> cabal install --only-dependencies
Resolving dependencies...
Notice: installing into a sandbox located at
/Users/timo/game-in-haskell/nehe-tuts/.cabal-sandbox
Configuring bindings-GLFW-3.0.3.3...
Building bindings-GLFW-3.0.3.3...
Failed to install bindings-GLFW-3.0.3.3
Last 10 lines of the build log ( /Users/timo/game-in-haskell/nehe-tuts/.cabal-sandbox/logs/bindings-GLFW-3.0.3.3.log ):

/System/Library/Frameworks/CoreData.framework/Headers/NSBatchUpdateRequest.h:41:1:
     note: 'assign' can be unsafe for Objective-C objects; please state explicitly if you need it
     @property (strong, readonly) NSEntityDescription *entity;
     ^

/System/Library/Frameworks/CoreData.framework/Headers/NSBatchUpdateRequest.h:42:18:
     error: unknown property attribute before ')' token
     @property (strong) NSPredicate *predicate;
                      ^
cabal: Error: some packages failed to install:
GLFW-b-1.4.6 depends on bindings-GLFW-3.0.3.3 which failed to install.
bindings-GLFW-3.0.3.3 failed during the building phase. The exception was:
ExitFailure 1

See http://hydra.cryp.to/build/606899/log/raw for a complete build log that shows the error.

Please make a comment here if you would like to take maintainership.

I'm relatively new to Stackage and the stack stack, so I don't know if this isn't feasible.

But having this library (and GLFW-b ofc) on Stackage would be great!

P.S.: Any suggestions on how to include it in a stack build anyway? I.e. is there are way to still load selected packages from Hackage?

Bindings-GLFW won't compile on my macOS 10.11.6: fatal error: OpenGL/gl.h: No such file or directory

Any ideas how I can resolve this issue?

Context:

$ stack install bindings-GLFW
Warning: File listed in .stack-work/downloaded/0pCfpnxANlB-/freetype2.cabal file does not exist: objs/ftmodule.h
Warning: File listed in .stack-work/downloaded/F_GRW2V-q8oW/nodejs-exec.cabal file does not exist: node/node
WARNING: Ignoring out of range dependency (allow-newer enabled): template-haskell-2.12.0.0. bindings-GLFW requires: >=2.10 && <2.12
bindings-GLFW-3.1.2.2: configure
bindings-GLFW-3.1.2.2: build

--  While building package bindings-GLFW-3.1.2.2 using:
      /Users/vilem/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.0.0.2 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /Users/vilem/code/github/lamdu/.stack-work/logs/bindings-GLFW-3.1.2.2.log

    Configuring bindings-GLFW-3.1.2.2...
    Preprocessing library for bindings-GLFW-3.1.2.2..
    In file included from GLFW.hsc:9:0:
    /private/var/folders/12/1kppc1y16nzfg7ntgz9pyvfc0000gn/T/stack15987/bindings-GLFW-3.1.2.2/glfw/include/GLFW/glfw3.h:156:25: fatal error: OpenGL/gl.h: No such file or directory
    compilation terminated.
    compiling .stack-work/dist/x86_64-osx/Cabal-2.0.0.2/build/Bindings/GLFW_hsc_make.c failed (exit code 1)

Right now, we're using pre-baked glfw_config.h in

glfw/include/os/unix-like/glfw_config.h

We don't have a way to turn on or off the Wayland and Mir CPP macros though since we don't build via CMake. We should probably add a way (via cc-options?) to turn on the different managers in the config if the proper cabal flag is requested.

glfw 3.1 supports Wayland and Mir in addition to X. It would be nice to be able to automatically determine which of these display servers is being used.

The [4] label both points to the glfw changelog and to the glfw-b github page.

I think someone’s forgotten to update the version number here. Shouldn’t it be 1? The glfw3.h header file might need to get updated then?

There are a few bug fixes across multiple platforms: https://www.glfw.org/changelog.html

In the original GLFW project, that dependency seems to be optional. As far as I know, this is a legacy fallback option. Does it make sense to require it in every Haskell build?

bindings-GLFW builds against bindings-DSL-1.0.17, not against 1.0.18

Preprocessing library bindings-GLFW-0.1.0...
In file included from GLFW.hsc:7:0:
/home/bergey/.cabal/lib/bindings-DSL-1.0.18/ghc-7.6.3/include/bindings.dsl.h:188:13: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
 bc_fielddata.n = 0; /* Avoid warning of unused variable */
             ^
compiling dist/build/Bindings/GLFW_hsc_make.c failed (exit code 1)
command was: /usr/bin/gcc -c dist/build/Bindings/GLFW_hsc_make.c -o dist/build/Bindings/GLFW_hsc_make.o -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads -D__GLASGOW_HASKELL__=706 -Dlinux_BUILD_OS -Dlinux_HOST_OS -Dx86_64_BUILD_ARCH -Dx86_64_HOST_ARCH -Iglfw/include/os/unix-like -Iglfw/include -Iglfw/src -I/home/bergey/.cabal/lib/bindings-DSL-1.0.18/ghc-7.6.3/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/lib/ghc/base-4.6.0.1/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/lib/ghc/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/lib/ghc/include/
Failed to install bindings-GLFW-0.1.0
cabal: Error: some packages failed to install:
bindings-GLFW-0.1.0 failed during the building phase. The exception was:
ExitFailure 1

I suppose this is actually a bug (or PVP issue) with bindings-DSL, but I don't really understand what's going on.

The test-suite for this package has been disabled in stackage because of this outdated dependency. When a fix is published to hackage please send a PR to re-enable the tests to stackage (it's in the skipped-tests section) or ping me.

Thanks!

The Cabal file places this code under BSD3, but the LICENSE file actually contains a BSD2 license.

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?

3.1.1 has some nice bug fixes and will most likely be an easy upgrade.
http://www.glfw.org/changelog.html

environment: M1 mac running Monterey

reproduction steps:
call GLFW.pollEvents

expected result:
works as documented

actual result:
Error'PlatformErrorCocoa: Failed to find service port for display

cause of the issue:
The latest release 3.3.2.0 of bindings-GLFW uses a version of GLFW that is broken on M1 macs. Updating to a newer GLFW fixes the problem. For example GLFW 3.3.8 used in commit f418294 of https://github.com/TristanCacqueray/bindings-GLFW.git does not show this issue and works as expected.

These additions were added in 3.1 and they need to make it into the bindings:

• Added GLFWcursor custom system cursor handle
• Added glfwCreateCursor, glfwCreateStandardCursor, glfwDestroyCursor and glfwSetCursor for managing system cursor images
• Added GLFWimage struct for passing 32-bit RGBA images
• Added monitor and adapter identifier access to native API
• Added glfwSetDropCallback and GLFWdropfun for receiving dropped files
• Added glfwPostEmptyEvent for allowing secondary threads to cause glfwWaitEvents to return
• Added empty test program for verifying posting of empty events
• Added glfwSetCharModsCallback for receiving character events with modifiers
• Added glfwGetWindowFrameSize for retrieving the size of the frame around the client area of a window
• Added GLFW_AUTO_ICONIFY for controlling whether full screen windows automatically iconify (and restore the previous video mode) on focus loss
• Added GLFW_DONT_CARE for indicating that any value is acceptable
• Added GLFW_DOUBLEBUFFER for controlling whether to use double buffering
• Added GLFW_CONTEXT_RELEASE_BEHAVIOR and values GLFW_ANY_RELEASE_BEHAVIOR, GLFW_RELEASE_BEHAVIOR_FLUSH and GLFW_RELEASE_BEHAVIOR_NONE for GL_KHR_context_flush_control support
• Added GLFW_INCLUDE_ES31 for including the OpenGL ES 3.1 header
• Added GLFW_FLOATING for creating always-on-top windowed mode windows
• Added GLFW_FOCUSED window hint for controlling initial input focus

Hi,
I'm having an issue with strdup which I noticed was in a prior issue (#11)

[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics\UI\GLFW\Types.hs, dist\build\Graphics\UI\GLFW\Types.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.22 ... linking ... done.
Loading package bindings-GLFW-3.1.1.2 ... linking ... ghc.exe: unable to load package `bindings-GLFW-3.1.1.2'
ghc.exe: warning: _vsnprintf from msvcrt is linked instead of __imp__vsnprintf
ghc.exe: C:\Users\Pawel\AppData\Roaming\cabal\x86_64-windows-ghc-7.8.3\bindings-GLFW-3.1.1.2\HSbindings-GLFW-3.1.1.2.o: unknown symbol `strdup'
Failed to install GLFW-b-1.4.7.2
cabal.exe: Error: some packages failed to install:
GLFW-b-1.4.7.2 failed during the building phase. The exception was:
ExitFailure 1

Here are my versions:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3

$ ghc --print-target-platform
x86_64-unknown-mingw32

$ ghc --print-build-platform
x86_64-unknown-mingw32

$ cabal --version
cabal-install version 1.22.0.1
using version 1.22.1.1 of the Cabal library

I checked if any earlier versions work, and apparently bindings-GLFW-3.0.3.3 works with GLFW-b-1.4.6 (or at the very least it compiles and installs while throwing a bunch of warnings).

Could it be that when the workaround was moved to win32_platform.h that it stopped working for 64-bit windows?

Hello,

I'm seeing the following issues when installing GLFW-b on OS X 10.6 / HP 2013.2.0.0 using cabal:

[1 of 1] Compiling Bindings.GLFW ( dist/build/Bindings/GLFW.hs, dist/build/Bindings/GLFW.p_o )
...
glfw/src/cocoa_window.m:77:0: error: incompatible types in return
glfw/src/cocoa_window.m: In function ‘createWindow’:
...
cabal: Error: some packages failed to install:
GLFW-b-1.1.0 depends on bindings-GLFW-0.0.1 which failed to install.
bindings-GLFW-0.0.1 failed during the building phase. The exception was:
ExitFailure 1

Is there anything I can do to fix this?

I already installed the 'non-b' GLFW package before and successfully compiled and ran a short example. I'm fairly clueless here, but I was surprised to learn that both bindings use the same module name, 'Graphics.UI.GLFW'. Is it possible to have them both installed at the same time, or am I causing problems by doing so?

Would love to try out GLFW-b, any fixes/help greatly appreciated!

@bsl how would you feel about this? I know you probably had some clear cut reasons to split them up but it looks like the only reverse dependency on bindings-GLFW is GLFW-b, and merging them would make management and testing easier (I've made a couple airhead mistakes pushing to the wrong repo, looking at the wrong changes, etc.).

Hello,

Thanks for your effort in maintaining the package.

The latest GLFW version is 3.2.1. Just want to check if there are any plans to upgrade the bindings.

Thanks

Could you please make bindings for these functions http://www.glfw.org/docs/latest/group__native.html

I am trying to build the latest version form hackage but I get the following error:

Preprocessing library for bindings-GLFW-3.3.2.0..
Bindings\GLFW.hsc:62 directive num cannot be handled in cross-compilation mode

It looks like the dev version of GLFW works on MacOS using MoltenVK now.
Would it be difficult to update these bindings as well?

Hello,

While trying to compile the test suite (or any other library depending on bindings-GLFW), I obtain the following error:

[1 of 1] Compiling Bindings.GLFW    ( dist\build\Bindings\GLFW.hs, dist\build\Bindings\GLFW.o )
[1 of 1] Compiling Bindings.GLFW    ( dist\build\Bindings\GLFW.hs, dist\build\Bindings\GLFW.p_o )
In-place registering bindings-GLFW-3.0.3.2...
Preprocessing test suite 'main' for bindings-GLFW-3.0.3.2...
[1 of 1] Compiling Main             ( Test.hs, dist\build\main\main-tmp\Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.21 ... linking ... done.
Loading package bindings-GLFW-3.0.3.2 ... linking ... ghc.exe: warning: _vsnprintf from msvcrt is linked instead of __imp__vsnprintf
ghc.exe: C:\Users\Vince\Documents\Coding\bindings-GLFW\dist\build\HSbindings-GLFW-3.0.3.2.o: unknown symbol `strdup'
ghc.exe: unable to load package `bindings-GLFW-3.0.3.2'

Here some version of the software I'm using:

[15:54:13] ~/Documents/Coding/bindings-GLFW> ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.2
[15:54:20] ~/Documents/Coding/bindings-GLFW> ghc --print-target-platform
x86_64-unknown-mingw32
[15:54:25] ~/Documents/Coding/bindings-GLFW> ghc --print-build-platform
x86_64-unknown-mingw32
[15:54:29] ~/Documents/Coding/bindings-GLFW> cabal --version
cabal-install version 1.20.0.2
using version 1.20.0.0 of the Cabal library

Is there any working around for this problem?

Thanks

Citing from http://hydra.cryp.to/build/627294/log/raw:

1 of 1] Compiling Bindings.GLFW    ( dist/build/Bindings/GLFW.hs, dist/build/Bindings/GLFW.o )

In file included from glfw/src/internal.h:74:0:
    0,
                     from glfw/src/context.c:28:

glfw/src/x11_platform.h:38:33:
     fatal error: X11/Xcursor/Xcursor.h: No such file or directory
     #include <X11/Xcursor/Xcursor.h>
                                     ^
compilation terminated.

Deja vu?

Currently Vsync doesn't work on Windows without this flag enabled.

glfw/glfw#24

Version 3.1.1 has been released to Hackage, but the corresponding changes are missing from the git repo.

This makes it confusing to understand what's happening, and fixing issues becomes much harder.

Hello,

Just want to check if you could make the glfw/ source a submodule, so, it gets easier to track with the origin.

Thanks

GLFW-3.3 was released on Wednesday. We should add the relevant function calls to this directory so that we can subsequently expose them via GLFW-b. All of the updates should go to the Upgrade-3.3 branch. This is a tracking bug to do so.

• Added glfwGetError function for querying the last error code and its description
• Added glfwUpdateGamepadMappings function for importing gamepad mappings in SDL_GameControllerDB format
• Added glfwJoystickIsGamepad function for querying whether a joystick has a gamepad mapping
• Added glfwGetJoystickGUID function for querying the SDL compatible GUID of a joystick
• Added glfwGetGamepadName function for querying the name provided by the gamepad mapping
• Added glfwGetGamepadState function, GLFW_GAMEPAD_* and GLFWgamepadstate for retrieving gamepad input state
• Added glfwGetWindowContentScale, glfwGetMonitorContentScale and glfwSetWindowContentScaleCallback for DPI-aware rendering
• Added glfwRequestWindowAttention function for requesting attention from the user
• Added glfwGetMonitorWorkarea function for retrieving the monitor work area
• Added glfwGetKeyScancode function that allows retrieving platform dependent scancodes for keys
• Added glfwSetWindowMaximizeCallback and GLFWwindowmaximizefun for receiving window maximization events
• Added glfwSetWindowAttrib function for changing window attributes
• Added glfwGetJoystickHats function for querying joystick hats
• Added glfwInitHint for setting initialization hints
• Added glfwWindowHintString for setting string type window hints
• Added glfwGetWindowOpacity and glfwSetWindowOpacity for controlling whole window transparency
• Added glfwSetMonitorUserPointer and glfwGetMonitorUserPointer for per-monitor user pointers
• Added glfwSetJoystickUserPointer and glfwGetJoystickUserPointer for per-joystick user pointers
• Added glfwGetX11SelectionString and glfwSetX11SelectionString functions for accessing X11 primary selection
• Added glfwRawMouseMotionSupported function for querying raw motion support
• Added headless OSMesa backend
• Added definition of GLAPIENTRY to public header
• Added GLFW_TRANSPARENT_FRAMEBUFFER window hint and attribute for controlling per-pixel framebuffer transparency
• Added GLFW_HOVERED window attribute for polling cursor hover state
• Added GLFW_CENTER_CURSOR window hint for controlling cursor centering
• Added GLFW_FOCUS_ON_SHOW window hint and attribute to control input focus on calling show window
• Added GLFW_SCALE_TO_MONITOR window hint for automatic window resizing
• Added GLFW_JOYSTICK_HAT_BUTTONS init hint
• Added GLFW_LOCK_KEY_MODS input mode and GLFW_MOD_*_LOCK mod bits
• Added GLFW_RAW_MOUSE_MOTION input mode for selecting raw motion input
• Added macOS specific GLFW_COCOA_RETINA_FRAMEBUFFER window hint
• Added macOS specific GLFW_COCOA_FRAME_NAME window hint
• Added macOS specific GLFW_COCOA_GRAPHICS_SWITCHING window hint
• Added macOS specific GLFW_COCOA_CHDIR_RESOURCES init hint
• Added macOS specific GLFW_COCOA_MENUBAR init hint
• Added X11 specific GLFW_X11_CLASS_NAME and GLFW_X11_INSTANCE_NAME window hints
• Added GLFW_INCLUDE_ES32 for including the OpenGL ES 3.2 header
• Added GLFW_OSMESA_CONTEXT_API for creating OpenGL contexts with OSMesa

Despite the fact, that the sources are on 3.0.4