7 Replies - 4934 Views - Last Post: 19 July 2015 - 09:18 PM Rate Topic: -----

#1 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

FreeGLUT won't link

Posted 18 July 2015 - 04:57 AM

I'm trying to get an example OGL program working from this book. However, it will not compile. I keep getting the following linker error.

error LNK1104: cannot open file 'freeglutd.lib' C:\Trash\ExperimenterSource\ExperimenterSource\Chapter4\Box\LINK

The primary problem with that is that I don't know why it is looking for this file, but there is no such file. The FreeGLUT download contains no such file and so no such file has ever been put on my computer which would pretty much explain why it can't find it.

Now this file is the "debug" version of the lib supposedly and you only get this error when trying to compile the debug version. If you compile it as a release version it compiles and links with no problems, except the program doesn't actually run but immediately crashes with the following cryptic error:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

Any ideas here? I've Googled this problem extensively since yesterday. Nothing I've tried seems to work and I have no idea what the problem is, let alone what the supposed solution is.

Is This A Good Question/Topic? 0
  • +

Replies To: FreeGLUT won't link

#2 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: FreeGLUT won't link

Posted 18 July 2015 - 05:11 AM

By renaming the release lib to freeglutd.lib and placing it in the main folder of my project I got it to compile as the "debug" version. However, now it just blows up like the release version (at least it's consistent behavior now). But this blows up before the program begins. I have a break point set on the first line of code and the program never gets there.
Was This Post Helpful? 0
  • +
  • -

#3 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: FreeGLUT won't link

Posted 18 July 2015 - 02:38 PM

Ok. I reduced the code down to this and get the same "Cannot find freeglutd.lib" error. (New project and haven't just renamed freeglut.lib freeglutd.lib because I'm trying to get this figured out and that's a ridiculous "solution".

#include <freeglut.h>

int main(int argc, char **argv)
{
	return 0;
}


With the include statement I have the problem. Without the include it compiles and runs.
Was This Post Helpful? 0
  • +
  • -

#4 ben255   User is offline

  • D.I.C Addict

Reputation: 44
  • View blog
  • Posts: 528
  • Joined: 09-September 13

Re: FreeGLUT won't link

Posted 18 July 2015 - 03:34 PM

dunno what else to expect with a language like c++ :P/>
cant handle the power of ogl

This post has been edited by ben255: 18 July 2015 - 03:35 PM

Was This Post Helpful? 0
  • +
  • -

#5 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: FreeGLUT won't link

Posted 18 July 2015 - 03:47 PM

You can't define FREEGLUT_STATIC because of the code below in freeglut_std.h:

/* Windows static library */
#   ifdef FREEGLUT_STATIC

#error Static linking is not supported with this build. Please remove the FREEGLUT_STATIC preprocessor directive, or download the source code from http://freeglut.sf.net/ and build against that.


The NDEBUG seems to be what's making it look for this file:

/* Windows static library */
# ifdef FREEGLUT_STATIC

#error Static linking is not supported with this build. Please remove the FREEGLUT_STATIC preprocessor directive, or download the source code from http://freeglut.sf.net/ and build against that.

/* Windows shared library (DLL) */
#   else

#       define FGAPIENTRY __stdcall
#       if defined(FREEGLUT_EXPORTS)
#           define FGAPI __declspec(dllexport)
#       else
#           define FGAPI __declspec(dllimport)

            /* Link with Win32 shared freeglut lib */
#           if FREEGLUT_LIB_PRAGMAS
#               ifdef NDEBUG
#                   pragma comment (lib, "freeglut.lib")
#               else
#                   pragma comment (lib, "freeglutd.lib")
#               endif
#           endif


Actually, it's completely ignoring this and uses the debug version regardless if NDEBUG is defined.
Was This Post Helpful? 0
  • +
  • -

#6 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: FreeGLUT won't link

Posted 18 July 2015 - 04:55 PM

Wow. I got it working but it was a mess. First I started over and created a new project from scratch. I'm not sure I can remember everything I did because I tried so many different things and most didn't work. I still don't think copying the release version of freeglut.lib to be freeglutd.lib is the "correct" way to handle this. I suspect there's supposed to be a debug version but it's undocumented. How am I the first person to run into this problem? lol



Grrr... spoke too soon. The x64 build runs but the 32 bit version crashes... Oh you gotta love this: all versions work except the 32 bit release version. It gives that same crazy won't startup error that basically tells you basically nothing but seems to indicate a dll is out of whack.

Ok. Got that one working too now. (I didn't have all the dll files copied into the 32 bit release folder. I had them for the debug and the 64 bit versions but not that one.) Maybe that's good since it reiterates what the solution was. Basically, I think there's supposed to ideally be a debug version of all these files and there are none included in the downloads.

All the DLLs went into the build directory (I'm not sure if there's a technical name for this). But I have my MSVC solution directory for the project and there is a Debug and Release folder below that which are the 32 bit debug and release versions not to be confused with the project folder of the same name which has all of these sub-folders as well but things will not work if you put these files in them.

So, 32 bit versions of all this goes in the debug folder and release folder:
freeglut.dll
glew32.dll
glewinfo.exe
visualinfo.exe


For the 64 bit version (since you probably primarily want to be compiling 64 bit these days but may want 32 bit as well just in case) you have to place the 64 bit versions of these same files in the Debug and Release folders that are under the x64 folder that is under the solution folder, not to be confused with the folders of the same name under the project folder which in my mind would be the place to put them, but not so much. Notice that the 64 bit version of the glew dll is named glew32.dll... because that makes total sense. If there's any doubt that this is the 64 bit version notice it has a completely different file size than the dll of the exact same name which is the 32 bit version.

I "believe" that in these locations, Visual Studio can just find them and you don't have to configure anything for it to see them after putting them in those locations. Notice we've got 4 separate copies - 2 dll files in 2 sets with a 32-bit set and a 64-bit set but both the release and debug versions being identical (they're all release versions).

You "might" be able to place these in system32 and SysWow64. That's what the original instructions said to do (which did not work and gave the errors mentioned before). I ignored that, started over, and did it like this and all I can say is "it works".

I don't know if it matters, but I also stopped following the instructions on where to get freeglut from and downloaded it from sourceforge. Those are the header files I'm using for freeglut. There are no lib or dll files in that download. So, "probably" the correct way to do this would be to compile the source files it contains into a dll and lib for all 4 versions (32/64 bit and release/debug). But we in the Microsoft world don't build libraries and there's no instructions but it's obviously different source files for every Operating System you compile for. There's a CMAKELists.txt but of course it has Linux line delimiters and the file is all but unreadable in Windows (open it with MS Word instead of Notepad should help).

I'm not messing with that today. Save that "adventure" for another day.

It seems to be giving that freeglutd.lib regardless of whether it is the debug version or not. It's basically saying it can't find the lib file. I placed the 32 bit lib files in the folder

C:\VirtuallyProgramming\OGL\lib

and the dll error goes away when you go into the project properties under Linker->General->Additional Library Directories and add that folder. You want to use C:\VirtuallyProgramming\OGL\lib\x64 for the 64 bit lib files not to get them crossed up.

Now this makes total sense, right? In order to make the dll error go away, you have to point it to the correct static libraries which it cannot use because if you set the defines to use the static library it will blow up with an error telling you that's a no-no. Ok. Whatever. But it works. All I can say is the dll error is there if you don't have the libs and the second you get it seeing the libs it stops complaining about not being able to find the dll.

Edit:It was a lib error and it goes away when you point the additional librarys to it. It's just been a long day and I'm tired and got confused on that.

Note that it runs just fine if you don't have a freeglut.lib file but it will continue to give the error if there is no freeglutd.lib even if freeglutd.lib is nothing more than freeglut.lib renamed.

Edit: Spoke too soon. It does care. I tried to compile the release version and it would not compile without freeglut.lib and immediately complained that it was missing. So, looks like you need both.

Really it's probably fine not to have a real freeglutd.lib file because are you really going to debug freeglut? I'm thinking it either runs or it doesn't and it's probably been pretty thoroughly tested. Hopefully, we will never have to try and debug it. Any bugs should be in your code, not in that lib file. So, having only a release version seems fine to me but it only looks for the debug version which there is no such thing from the downloads I've seen. I suspect that the proper way to remedy this is to build your own freeglut dlls and libs in both 32 bit and 64 bit versions and that the whole problem here revolves around the fact that the people who built the versions everyone downloads to use did not do that like they should have.

So, as you probably noticed, I have a folder C:\VirtuallyProgramming\OGL\ and below that I have a lib folder and an include folder (You can name these what ever you like as long as you point to them with the right name). The include folder has a GL subfolder with all the header files. I don't know if you need a sub-folder; everyone does it that way in all the OGL instructions I've seen. I'm sure it's not necessary, but that's the way I did it.

In the project properties under C/C++->General->Additional Include Directories I have C:\VirtuallyProgramming\OGL\include\GL for all of the header files. There are, of course, no 32 or 64 bit versions of header files since they are uncompiled source code. So, all 4 builds share the same folder.


I have the following header files in there:
freeglut.h
freeglut_ext.h
freeglut_std.h
glew.h
glext.h
glut.h
glxew.h
wglew.h


And at the beginning of the code I have:
#include <glew.h>
#include <freeglut.h>
#include <glext.h>
#pragma comment(lib, "glew32.lib")



Anyway, there's probably more than one correct way to set this stuff up. But I finally got the program to run with no errors by doing it this way. I ended up copying the source code from the original sample file into my newly created project and Main.cpp file. Its drawing wire frame boxes using OGL 4.3. So it appears to be running with no issues now. Now maybe I can learn me some OpenGL!

This post has been edited by BBeck: 18 July 2015 - 05:30 PM

Was This Post Helpful? 0
  • +
  • -

#7 stayscrisp   User is offline

  • フカユ
  • member icon

Reputation: 1040
  • View blog
  • Posts: 4,326
  • Joined: 14-February 08

Re: FreeGLUT won't link

Posted 19 July 2015 - 08:37 AM

To be honest I would drop freeGLUT and use SDL. Mainly because it feels like you have a lot more control, essentially SDL will be your entry point and from there you can just code your own event loop and easily integrate with other libraries. I recently created a little test OpenGL project using SDL and easily had it running on a few different platforms with a few preprocessor directives to use OpenGL ES when needed. It's just nice to have a library that creates an openGL context for you and then leaves you to it :)/>

Much nicer for cross platform development.

This post has been edited by stayscrisp: 19 July 2015 - 08:56 AM

Was This Post Helpful? 0
  • +
  • -

#8 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: FreeGLUT won't link

Posted 19 July 2015 - 09:17 PM

I'll have to try that. Right now I'm just trying to learn, so I'm using the libraries that the tutorials and books say to use for the examples. But after I kind of figure out what's going on, I'll have to give that a try. Thanks!
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1