Details are here: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=261553 To put it short, I'm using the latest version (which I heard is pretty old) of GLUT (3.7.6) on MinGW. It refuses to link...or at least link properly. The glut32.lib links in Visual Studio but nothing does in MinGW. NOTE: I HAVE TOLD THE COMPILER TO LINK. Please read the details for additional information which I think will be necessary to answer the question. Thanks.

It doesn't make really clear in the other page, but did you built glut yourself? The precompiled version usually found on the web is built with some GCC 3.X version and is incompatible with 4.X. If it's the case, grab a copy of freeglut, import the VS project with codeblocks and build it, works out-of-the-box (at most you'll have to change a few linker options, I don't remember properly..)(or either grab MSYS to do the job :). I currrently have 4.3.2 and it works.

For the linking, make sure you have -lopengl32 *after* glut32, and if I'm not mistaken you also need -lgdi32 -lwinmm for it to build correctly.

Yes, I built GLUT (3.7.6) myself. I used GCC 4.4.0 on MinGW to do so.

I just tried it again with those 2 other libraries and it still doesn't work. Order is as follows:

glut32
opengl32
gdi32
winmm

Same error. I also checked and made sure I have no other copies of GLUT in the path by renaming libglut32.a which, as expected, gave me a not found error.

Could it be that GCC doesn't support something as old as the original GLUT?

If you really want to use GLUT for "cross platform development", I strongly suggest you to use freglut, that's what you'll find on most systems, the code will be the same in 99.99% of places plus you some additional features :). Looking into my old glut header file, I found this:

#ifdef __MINGW32__#  define _STDCALL_SUPPORTED#endif

which causes every glut function to use __stdcall calling convention, which relates to how GCC store function names in object files, if I'm not mistaken __cdecl *doesn't* precede the function name with an underscore, and __stdcall does it (or the opposite :p). The "official" glut sources includes windows.h in some place, which #defines CALLBACK as __stdcall, causing those functions not to be found by the linker (by, as above, an extra[or not] underscore). Either include the #define above in your glut.h or use freeglut, it should work.

I just tried building freeglut. I tried to do it with a makefile first. It appeared to be successful until I realized that it produced no output besides a bunch of object files. Except for that libglut.a which I have no idea why it would generate that. But no dlls, nothing.

I tried it with Code::Blocks by converting the VS solution. The compilation worked with the libfreeglut.a being produced. Except I got a bunch of linking errors. The errors for OpenGL were easy to solve...I just linked to libopengl32.a and thought that was the end of them. Except I still ended up with a bunch of linking errors to GDI functions (or so I think from searching the web) such as `undefined reference to wglGetProcAddress@4'. I added in gdi32 and winmm (both of which do exist) and came up with the same result. Of course, it worked perfectly when I built it directly from Visual Studio.

Is it problem with my GDI library? Do I have to build that to fix it?

Thanks for the reply.

BTW, I'm also going to try openglut to see if that ends up any different although it does appear to be a dead project but...so is GLUT so...

UPDATE: OpenGLUT gives me the exact same result as FreeGLUT. I thought it might be a problem with MinGW so I reinstalled it to no avail.

I just tested with Cygwin and strangely, it worked. So now, I'm narrowing the problem down to MinGW. I can't use Cygwin for the project because of the fact that it is closed source and anything built with Cygwin must be under the GPL. Note that the libglut32.a came with Cygwin when I installed it a while back.

UPDATE AGAIN: I copied the library in Cygwin into the MinGW lib directory and it actually works. The thing now I'm worried about is if that libglut32.a & glut32.dll was built with Cygwin because if it is, then anything using it must be open sourced like above. Most of the libraries between Cygwin and MinGW seem identical so it seems okay for use in a closed source project. If someone can tell me for sure...thanks.

[Edited by - Caglow on August 1, 2009 8:34:08 PM]

Quote:tried it with Code::Blocks by converting the VS solution. The compilation worked with the libfreeglut.a being produced. Except I got a bunch of linking errors. The errors for OpenGL were easy to solve...I just linked to libopengl32.a and thought that was the end of them. Except I still ended up with a bunch of linking errors to GDI functions (or so I think from searching the web) such as `undefined reference to wglGetProcAddress@4'. I added in gdi32 and winmm (both of which do exist) and came up with the same result. Of course, it worked perfectly when I built it directly from Visual Studio.

I just built freeglut from source by importing the VS project and using GCC 4.4.0 from mingw.org. I set the project linker options to include opengl32, gdi32 and winmm.
I built a small program with it that worked just fine. The full command line used:gcc gluttest.c -o gluttest -lglut32 -lopengl32 -lwinmm -lgdi32. You must be forgetting something in the process

Command-line looks exactly the same. In addition, it also built on Cygwin with the makefile but failed on MinGW...even after I completely deleted everything in the MinGW folder and reinstalled it. However, Cygwin uses 4.3.2...

I ended up abandoning GLUT entirely and sticking with raw openGL. It wasn't much fun, but in point of fact once you get the basic initialization working (which is mostly what I wanted GLUT for) and wrapped in a class, the pain is over and doesn't need to be revisited.

I have the hideous feeling that openGL is slowly dying; this bugs me, given the amount of code I have that uses it.