linking to glew in c

Question

I can't link properly to glew.

I have done:

#define GLEW_STATIC
#include "glew/glew.h"
#pragma comment(lib, "glew/glew32s.lib")

However, I still get the error:

LNK2019: unresolved external symbol __glewGenBuffersARB referenced in function initialize

Koh

Are you building a 32 or 64 bit program, and are you using the correct corresponding glew32s.lib file? – Negate

Maybe you should use <> brackets in the #include? – Henn

It seems that the linker does not find the glew .lib file. Try checking that it is in the library search path. – Maldives

@EitanT If that was the problem it would fail in compilation time. In this case the failure is in the linking time. – Maldives

@Negate I am running on a 64 bit machine. I'm not sure how to rebuild glew to run on 64bit. – Koh

@TalDarom I double checked the file location just now, it's there. – Koh

@StormKiernan, where is there? I belive it is where you put it, but is this path in the linker search path? try including the full path in the library name just to check. The other option is that you are using a 32 bit version of the library. Did you download the compiled library or built it yourself? – Maldives

@TalDarom I must have downloaded the 32 bit version instead of the 64 bit version. I will need to build it or download the 64 bit version. The "glew" folder is in the build directory, so that's not the issue i don't think. I remember that it gives me errors when it cant find the file. – Koh

You just need to make sure that if you're building a 32 bit program that you use 32 bit glew, and if you're building a 64 bit program that you use the 64 bit version. If you build both, you'll have to use a different glew32s.lib for each version. – Negate

Answer 1

Save yourself a lot of trouble and just put the glew.c file into your project. I never bother with linking to a glew library externally. Once you have that in there, the GLEW_STATIC macro will work. It's only one file, and (if this matters to you) it will carry nicely across platforms (rather than having to rebuild several OS-specific libs).

Zayin

No, you should never add external library source files directly into on own's project build. Most software packages, and GLEW is among them, require a build configuration step in their build system in which the properties of the build system and presence of required dependencies are checked. If you want your executable binary being easily redistributable you should make a special purpose build of the required libraries, that then either link statically, or are dynamically linked to a specific path relative to the binary. Both options are easily controlled by linker options. – Adumbrate

BUT YOU NEVER INCLUDE EXTERNAL SOURCE FILED NAKED IN YOUR OWN PROJECT!!! It's a recipe for disaster. – Adumbrate

@Adumbrate What you're saying can be true of more complex libraries, but GLEW is not one of them. You may like lugging around 32-bit builds, 64-bit builds, ARM builds, etc. of GLEW, but I'd rather just build it straight away. Your proposed solution wastes time all to be pedantic about something that does not matter. – Zayin

@TheBuzzSaw: Of course it matters. And if you've organized your build environment well, it's a matter of a few seconds to include a library as an external sub build into your project. Build systems like CMake really do help with this. – Adumbrate

@Adumbrate You have fun with that. I still don't know where you get off DOWN-VOTING the answer that solved this person's problem over 3 months ago. You are on quite the crusade. – Zayin

@TheBuzzSaw: It's not a crusade (well maybe it is). But I have so often people ask me for help with their projects and it turns out their build process was a complete mess. So whenever I see a suggestion like yours, I cannot help but point out the problem this causes in the long run. – Adumbrate

I just came here to upvote this answer and laugh at all those people who failed to realize that glew.c can be put into a lib folder just like the rest of libs, compiled in libs folder to an object file, and then linked like any other lib but in a "hacky" way from different directory, and glew.h can just be kept in includes like normal, yeah wow your makefile will contain 2 lines for compiling an external library which is a single file, TOTAL DISASTER. I spent 4 hours yesterday trying to get glew to link statically with mingw but nothing has worked so I just compile it myself now, thank you. – Felizio

Answer 2

I want to extend the excellent @TheBuzzSaw's idea by providing a more detailed answer for a cmake project.

1. Download GLEW sources from here.
2. Unzip the archive and copy two files (src/glew.c and include/GL/glew.h) into your project's directory.
3. Edit glew.c so that the beginning of the file looks like this:

#ifndef GLEW_INCLUDE
#include "glew.h"  /* Point to local glew.h file. */
#else
#include GLEW_INCLUDE
#endif

4. Use the following in your main.cpp file to include static GLEW correctly:

#define GLEW_STATIC
#include "glew.h"

5. To build the project, you must compile and link the static GLEW library. Sample CMakeLists.txt file with the use of copied files:

cmake_minimum_required(VERSION 3.17)
project(your-project-name)

add_library(STATIC_GLEW glew.c)
add_executable(your-project-name main.cpp)


target_link_libraries(your-project-name STATIC_GLEW)

Now, you should be able to build your project without any linking errors 🎉

Villeinage