16

I am having issues compiling a basic openGL program on VS 2012. I get a build error upon compiltation giving me:

1>LINK : fatal error LNK1104: cannot open file 'glew32.lib'

I followed the instructions given to me by the documentation for GLEW.

In your OpenGL project open Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies -> add glew32.lib.

Also you must include #include in your sources; For that add path to your glew folder: Project -> Properties -> Configuration Properies -> General -> VC++ Directories -> Include Directories and Library Directories;

C/C++ Tab -> General -> Additional Include Directories - Add lib folder there

I have also added the glew32.dll onto my Debug folder within my project folder along with the executable. So far I keep getting this error.

If you need any more further clarification of the steps I have done please don't hesitate to ask

genpfault
  • 51,148
  • 11
  • 85
  • 139
Jebathon
  • 4,310
  • 14
  • 57
  • 108
  • I don't know how to format the quote - if a moderator can fix this for me – Jebathon Jan 01 '14 at 21:15
  • What happens if you temporarily copy `.lib` file to some existing valid directory, like `$(WindowsSdkDir)\lib`? – Dialecticus Jan 01 '14 at 21:27
  • Do you have glew32.lib? – drescherjm Jan 01 '14 at 21:28
  • I am astonished what drove the original author to claim a mandatory step to be OPTIONAL. This is required. – IInspectable Jan 01 '14 at 21:30
  • Don't put **glew32.dll** in your Debug folder. MSVC is setup to run your applications in your project/solution's root directory by default when you run it through the integrated debugger/execution command. If you put a ***single copy*** of all of your dependency DLLs there, then you do not have to put redundant copies in each of the build configuration directories (e.g. `Release`, `Debug`, `MyCustomBuildConfig`). – Andon M. Coleman Jan 01 '14 at 21:31
  • @drescherjm yes. Why would you ask that? – Jebathon Jan 01 '14 at 21:34
  • @AndonM.Coleman I did that as a solution to the already existing problem. It may help but without it the problem is still the same – Jebathon Jan 01 '14 at 21:35
  • Glew32.lib is not part of the Windows SDK, you need to supply it yourself. Type "glew32.lib" in a google query and take the first hit. – Hans Passant Jan 01 '14 at 21:41
  • 1
    [Linker Tools Error LNK1104](http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx) lists a number of possible causes. Can you eliminate all of them? – IInspectable Jan 01 '14 at 21:45
  • @HansPassant I got the OpenGL SDK – Jebathon Jan 01 '14 at 21:54
  • @IInspectable after some thought looking at all those options the only potential issue could be: "Another program may have the file open and the linker cannot write to it" – Jebathon Jan 01 '14 at 21:57
  • Well, don't make us or the linker guess at where you put it. Add it to the linker's General + Additional Library Directories setting. – Hans Passant Jan 01 '14 at 21:57
  • 1
    possible duplicate of [Visual Studio error: LNK1104: cannot open file 'kernel32.lib' - only in WP8 projects / Win32 builds](http://stackoverflow.com/questions/21056470/visual-studio-error-lnk1104-cannot-open-file-kernel32-lib-only-in-wp8-proj) – user3791372 Aug 19 '14 at 12:57
  • This worked for me :D Pan.student's reply to Edward83! http://stackoverflow.com/questions/16978418/cannot-open-file-glew32-lib –  Jan 07 '15 at 20:49

5 Answers5

15

In all honesty, there is no real benefit to using the DLL version of glew (short of reduced executable size, but this hardly matters on modern Windows PCs).

It is not like you can simply drop a new version of the DLL into your application and use extensions that you never used before. Likewise, bug fixes are so infrequent/unnecessary with a library that basically just parses the extension spec. files that using the DLL as a means of fixing extension loading bugs in shipped software is also not practical. Statically linking to glew (this means glew32s.lib) makes much more sense in the long run.

The static linking library is also more portable on Windows, it will work with MSVC and MinGW (whereas the DLL library only works with MSVC). Link against glew32s and put that in whatever directory you decided to use for additional library dependencies.


Here is a sample solution configuration for a project I wrote that uses glew. I have established a convention for this particular software where compile-time dependencies are stored under platform/<Subsystem>. Thus, I have glew32s.lib (32-bit) and glew64s.lib (64-bit) in ./Epsilon/platform/OpenGL/glew{32|64}s.lib

  enter image description here

Andon M. Coleman
  • 42,359
  • 2
  • 81
  • 106
  • I only have glew32 (without the s) within GLEW 1.10 package. Can you elaborate when you mean "Statically" linking to GLEW? – Jebathon Jan 01 '14 at 22:01
  • @BDillan: There are two versions of GLEW. There is the DLL (dynamic) version and then there is the one that is completely built-in to your software when you compile/link it (static). I always compile glew from source, but the binary archive [here](http://sourceforge.net/projects/glew/files/glew/1.10.0/glew-1.10.0-win32.zip/download) contains both the dynamic and static libraries under: **lib/Release/Win32** (32-bit) and **lib/Release/x64** (64-bit). It uses the name `glew32` for both Win32 and x64, for my software I actually renamed the 64-bit version as you can see in the diagram I listed. – Andon M. Coleman Jan 01 '14 at 22:11
2

Steps to Use Classes form another project (Add header and solver linker errors)

  1. To be able to add the header from another project, first go to "Properties > c++ > General > Additional Include Directories" and add the directory that contains the header. Now you will be able to add the header of the class from the other project, but running the project will still cause Linker Errors.

  2. Add __declspec(dllexport) before the class you are using for the other project. This can be added in the header file of that class. This should be added right before the function or variable or class name. Now you will get a lib file. (if placed in wrong place, you can get this warning: https://msdn.microsoft.com/en-us/library/eehkcz60.aspx)

  3. "Properties > Linker > Additional Library Directories". Specify the location of the lib file that is generated.

  4. "Properties > Linker > Input > Additional Dependencies”: Add the name of the lib file.

Mohith Maratt
  • 171
  • 1
  • 5
1

This sounds like the library has been specified as a dependency, but the linker/additional search path(s) has not been set to include the directory where the library is located.

This may help.

FuzzyBunnySlippers
  • 3,387
  • 2
  • 18
  • 28
1

It happened to me under this situation, I clean the solution and build it again, then many errors like LNK1104 occur.

After trying to restart IIS, I build solution successfully without LNK1104 errors. I do not know why, but restarting IIS takes much more time than normal, so I guess something is used by other IIS worker process.

Just give a shot to see if this magic happens on you.

David
  • 1,646
  • 17
  • 22
1

This question is old and marked solved, but I had a similar problem symptoms with a completely different solution. So just in case anyone else stumbles in here:
It appeared that because I had 2 projects under one solution (a dll and an exe), the building order was mixed (from the output window):

1> Rebuilding project1..
2> Rebuilding project1..
1> file1.cpp
2> file1.cpp

and so on. By the message you copied, it appears you too have more than one project under one solution. One project was looking for the *.lib file that the other build hadn't created yet.
Solution:
Right click on "main" project -> Build Dependencies -> Project Dependencies.. -> Mark which project the main one depends on.

yoad w
  • 315
  • 3
  • 10