mrgretchev wrote on Sunday, May 02, 2010:
Greetings,
I’ve been trying to get GLFW to work under Windows 7 using Visual Studio 2010,
but have had no luck so far. I tried using the compiled library on the main
website which did not seem to work, and I’m unable to compile it from command
line (nmake was throwing errors).
Has anybody else had this problem?
Thanks.
elmindreda wrote on Sunday, May 02, 2010:
I just built the library and all tests and examples on Windows XP using Visual
C++ 2010. Everything seems to be working.
You seem to be using version 2.6. Version 2.7 is nearly done but not released
yet (sorry about that), and is available in the GLFW Subversion repository.
You may have better luck using that.
sydbod wrote on Friday, May 07, 2010:
Under both Win7 and WinXP,
I did manage to compile version 2.6 from source using Visual Studio 2010
Express with no major problems.
Also ran some simple tests putting basic triangles to a window using the
library and also the DLL with no apparent problems, using Visual Studio 2010
Express again.
Have not tried Version 2.7 yet as I am having trouble compiling for X11 under
Linux. (still learning this OS)
This file contains any messages produced by compilers while
running ./compile.sh, to aid debugging if ./compile.sh makes a mistake.
./compile.sh: checking whether we are using GNU C
./compile.sh: cc -E conftest.c
./compile.sh: Checking for X11 RandR support
./compile.sh: gcc -c conftest.c 1>&5
conftest.c:1:22: error: X11/Xlib.h: No such file or directory
conftest.c:2:35: error: X11/extensions/Xrandr.h: No such file or directory
./compile.sh: failed program was:
#include <X11/Xlib.h>
#include <X11/extensions/Xrandr.h>
...........etc
Will look into this a bit closer when I figure out what I am doing.
elmindreda wrote on Friday, May 07, 2010:
Yes, I forgot to mention that I used the Express version of Visual C++ 2010.
It looks like you didn’t install the headers for X.
sydbod wrote on Sunday, May 09, 2010:
Sorry for hijacking this thread.
Thanks for that, yes “libx11-dev” was not installed. It appears that more
libraries are required.
Is there a complete list of what libraries are required to be installed on a
Linux platform to compile/create this framework?
dalfy wrote on Sunday, May 09, 2010:
You don’t need much but the packaging vary from one distribution to another.
For example on slackware if you have X, mesa, and the kernel headers installed
you should be able to built without issue.
On other distro I can’t tell the list of package involved. You need the
development package for the following software:
kernel (headers only)
X11
OpenGL
GLIBC
I think that’s all you need.
Good luck
Olivier
sydbod wrote on Sunday, May 09, 2010:
Thanks for that dalfy,
Am working with Ubuntu 10.04 using the ATI 10.4 FGLRX video driver.
have installed
"libx11-dev"
“libglu1-mesa-dev”
“libgl1-mesa-dev”
Now the 2.7 code appears to compile with no errors.
It may be a good idea if a sticky was created with what support libraries are
required for the various operating systems. It sure would help people like me
(those that don’t know what they are doing). 
sydbod wrote on Sunday, May 09, 2010:
Nope, the samples will not run with this compilation.
From within the glfwOpenWindow() function
if( _glfwWin.glMajor > 2 )
{
_glfwWin.GetStringi = (PFNGLGETSTRINGIPROC) glfwGetProcAddress( "glGetStringi" );
if( !_glfwWin.GetStringi )
{
_glfwPlatformCloseWindow();
return GL_FALSE;
}
}
This part is returning “GL_FALSE”.
Will look into it a bit more and if I can not sort it out, then I will start a
new thread just for this problem.
Thanks everyone for your help.
(never thought working under Linux was going to be so hard)
tiagomodesto wrote on Tuesday, September 14, 2010:
Hi, back to the subject, I have the same problems setting up GLFW on Visual
Studios 2010 in Win7 64.
I had success in compile the GLFW library to use in static mode. But when I
run a single program the glfwInit() returns GLFW_FALSE.
Anyone have any idea why this is happening???
Thanks…
elmindreda wrote on Tuesday, September 14, 2010:
sydbod: If you are using the GLFW build system, it probably didn’t find any
method of retrieving OpenGL extension entry points. If you are building GLFW
with your own build system, you should define the appropriate macro. See
x11_glext.c for details.
tiagomodesto wrote on Tuesday, September 14, 2010:
Hi, thanks for the fast reply.
I used the debug and the problem is in the line _glfwLibrary.Libs.gdi32 =
LoadLibrary( “gdi32.dll” );
The function LoadLibrary( “gdi32.dll” ) returns NULL, but I don’t know why…
Any ideas???
Thanks again!!!
elmindreda wrote on Tuesday, September 14, 2010:
tiagomodesto: Er, wow, hmm. Are you building for Win64?
tiagomodesto wrote on Tuesday, September 14, 2010:
I will try to go back to windows xp 32 doing the same procedures to see if
works. If works probable is some kind of incompatibility with win7 64… I will
post tomorrow.
Thanks any way…
marksibly wrote on Wednesday, October 20, 2010:
Hi,
Just got bit by this and the problem with glfwInit() failing is due to
unicode vs MBCS issues.
Change each LoadLibrary in win32_init.c to LoadLibraryA to fix.
Bye!
Mark
marksibly wrote on Wednesday, October 20, 2010:
Hi,
Actually, GLFW looks like it’s totally unicode unaware on win32.
After fixing the above, the next issue was with glfwOpenWindow - the title was
garbled when building for unicode.
Again, the solution is to either change the CreateWindow to CreateWindowA, or
use proper unicode strings.
Think I’ll stick with MBCS builds for now!
Bye,
Mark
uelkfr wrote on Tuesday, December 07, 2010:
Hi, I use Windows 7 and Visual Studio 2010. Same as marksibly I need to
complile in Win x64 Unicode configuration. When I changed to x64 there are
more warnings arised, but it’s compiled successfully. When I changed from MBCS
to Unicode a lot of warning in building GLFW.vcproj, but also compiled
successfully. Then I tried to build gears.vcproj. No warning, successfull
build.
uelkfr wrote on Tuesday, December 07, 2010:
I mean is it possible to add Debug x64 and Release x64 in Configuration
manager of GLFW.sln please? I know its hard to control x86 and x64 builds, but
x86 unperspective