GLFW-0.5.0.0 is released
There is now a new GLFW package on hackage with version number
0.5.0.0. Maintainers of packages that depend on GLFW may want to
update your packages since (1) GLFW-0.4.2 is mostly broken on OS X
Lion (10.7); (2) there are incompatible API changes.
Notable changes include (but not limited to):
1. It now uses GLFW C library version 2.7.2 on all platforms.
2. It still tries to compile and build a static version of the C
library on all platforms. If this is not what you want, use '--flags
dynamic' to dynamically link to pre-installed glfw C library on your
system.
3. It nows does a much better job at configuring itself on Linux and FreeBSD.
4. There is an outstanding bug preventing GLFW programs to be invoked
from GHCi on OS X. One has to compile before running GLFW programs.
5. Documentation has been improved, and there are also API changes
affecting window params and hints. See the hackage documentation for
details.
6. An example program and detail change log are included if you unpack
the source.
Many thanks to Marc Sunet and a lot of other people for sending in bug
reports and helping out with this upgrade. Marc is now also a
maintainer of this package. Please send your bug report to either of
us or to the GLFW mailing list
On Sat, Jan 21, 2012 at 4:32 AM, Paul Liu
There is now a new GLFW package on hackage with version number 0.5.0.0.
Congrats! [snip]
4. There is an outstanding bug preventing GLFW programs to be invoked from GHCi on OS X. One has to compile before running GLFW programs.
Does it still happen with -fno-ghci-sandbox? That fixes these sort of bugs with GLFW-b (and other libraries). If so, then the cause of the problem is the use of thread local storage in the vendor APIs (OpenGL on OSX is an example). I hope that helps, Jason
On Sat, Jan 21, 2012 at 2:05 PM, Jason Dagit
4. There is an outstanding bug preventing GLFW programs to be invoked from GHCi on OS X. One has to compile before running GLFW programs.
Does it still happen with -fno-ghci-sandbox? That fixes these sort of bugs with GLFW-b (and other libraries). If so, then the cause of the problem is the use of thread local storage in the vendor APIs (OpenGL on OSX is an example).
Thanks for the tips! As I'm testing now, ghci -fno-ghci-sandbox only seems to work with dynamically linked libraries, i.e., with GLFW-b, or GLFW installed with "--flags dynamic". Statically compiled GLFW C library would still give the "__NSCFString autoreleased with no pool in place" error. -- Regards, Paul Liu
participants (2)
-
Jason Dagit -
Paul Liu