Windows Nightmare with glew, glfw and code blocks

/**
* Incredibly Frustrated rant starts here
*/
I am try to do on windows what I did on Ubuntu in 10 minutes
I have been trying to do this for 4 days now.
It is an endless rabbit hole of looking up a tutorial to do X, which requires me to figure out how to do Y, and then tutorials on Y will require Z and so on, and you can get that any time it involves the IDE those on windows will be using visual studio rather than code blocks, and if I do find a tutorial on code blocks, it will be for Linux and whoever posted it will have neglected to mention which OS they were actually using, and the tutorials will all be 3 to 6 years old, all use different methods to accomplish what appears to be very similar tasks or in some cases are outright wrong. So after 4 days of trying to get this working on my own, I am asking
/* End of Incredibly Frustrated Rant */

How do I actual get what is described in this particular tutorial/guide to work:

http://www.learnopengl.com/#!Getting-started/Creating-a-window

I managed to get code blocks to use SLI2, SLI2 image and mixer, and some parts of opengl are usable, but for love nor money I can't get glew or glfw working outside of Ubuntu.

but going from the top of the guide page I got past the first cmake bit in the glfw part to the compiling section.

"In the build folder a file named GLFW.sln can be found and we open it with Visual Studio 2012. Since CMake generated a project file that already contains the proper configuration settings we can hit the Build Solution button and the resulting compiled library can be found in src/Debug named glfw3.lib (note, we're using version 3)."

Obviously, I am not using visual studio, so I got a GLFW.cbp file, opened up that in code blocks, and figured that rebuild and then build would be the equivalent of build solution in visual studio.
The problem is I can't find the file I am supposed to get in return anywhere.
There is no glfw3.lib on my C drive (I am assuming it is still version 3 since the glfw folder is vr 3.1.2), so where am I going wrong? The file isn't in the directory with the project file, and a c drive search doesn't locate it

This can't be as hard to do as it seems v.v
The build process generates the output somewhere, which could be as simple as a "bin" folder in the project directory (the area that was generated by CMake). If you didn't find it just by searching, you should check to make sure the build actually completed successfully (e.g., no linker errors or anything).
Unfortunately, 0 errors and 0 warnings. v.v
At this rate I may as well install Visual Studio and then open that can of worms too so I can start the whole process over and still be no closer to what I actually want.

Don't suppose I can use code blocks on Ubuntu to produce a file I can run on windows? >.>


Right... I checked the precompiled versions of glfw and the mingw version doesn't contain a .lib file... only the VS versions do.
So now I am totally at a loss. are .libs only a VS thing that I shouldn't have been looking for at all?
Gods java is so much easier v.v

OK. the files I need are glew32.dll, libglew32.a and libglew32.dll.a
I have them. Now all I need is to figure out what to do with them.
Last edited on
Building on Ubuntu will produce you binary files for your environment unless you cross-compile, which is another process entirely.

From my understanding, *.a files are static libraries for *nix environments, and won't do you any good on Windows. *.lib is the Windows "equivalent".

There are two ways to link to a library: statically or dynamically.

To link statically on Windows, you need a *.lib file to link to that will then be built into your executable.

To link dynamically, you need a *.lib file to link to that defines what the library provides (this is sort of like a "header" for the library). You will then need the *.dll to be accessible to your application at runtime (this is the "source" for the library). This means the DLL will need to live either in your PATH somewhere or in the working directory of the executable.

In general, these library files do not work across compilers, so if you have VS pre-compiled files they will not link with a non-VS toolset.

If you check your settings for the generated Code::Blocks project, there has got a be a setting for where to produce the output binaries. That's where you will need to check.

Once you have those, it is a matter of putting them where your application needs them. I believe Code::Blocks has set directories it will look for library files, so you may just place the GLFW library files wherever C::B wants them to be.
From my understanding, *.a files are static libraries for *nix environments, and won't do you any good on Windows. *.lib is the Windows "equivalent".
The .a and .lib extensions are literally just that. They don't actually mean that a format can only run on *nix environments or Windows environments. In fact, MinGW usually gives the files that it builds the .a extension.

In general, these library files do not work across compilers, so if you have VS pre-compiled files they will not link with a non-VS toolset.
This isn't true. I from my experience, MinGW isn't too picky when you hand it a .lib file built with Visual Studio.

I'm not 100 percent certain that this applies to precompiled headers as well, though.
________________________________

You should be fine just plopping in any library file that says that it was built for Windows.
Yeah, I managed to clear all the errors, I found a tutorial for installed GLEW and GLFW for MinGW on Windows, and finally managed to clear all the errors I was getting when I build the project, now I just need to figure out this odd error when i run it " The Procedure entry point glewInit@0 could not be located in the dynamic link library <path to project file>\Debug\GLDisplayTest.exe "
I am guessing something isn't going where it should be.

Got it!
uninstalled everything and went through the entire process, including installing MinGW, code blocks and gcu make, and cmake and... really. started over from scratch and did everything over with the process as I know it now, one step at a time, from the beginning.
I think what really screwed me over was the differences between the process for VS and Code Blocks and the fact that tutorials rarely ever mentioned what OS they were aimed at X.x
On the bright side, I think I have a fair idea now of where everything is and why it is there.
And now everything works ^.^
So I can go off and find out what else I need and go through this process again >.>
Last edited on
Topic archived. No new replies allowed.