IGTHORN wrote:
I'm giving up on this endeavour.
Don't do it. That's what the computer wants you to do!
IGTHORN wrote:
Removing the .lib reference and adding the glew.c I now get
Code:
obj\Debug\glew.o:glew.c|9101|first defined here|
obj\Debug\main.o||In function `_Z10initShaderv':|
main.cpp|57|undefined reference to `__imp____glewCreateShader'|
main.cpp|58|undefined reference to `__imp____glewShaderSource'|
main.cpp|59|undefined reference to `__imp____glewCompileShader'|
main.cpp|61|undefined reference to `__imp____glewCreateShader'|
main.cpp|62|undefined reference to `__imp____glewShaderSource'|
main.cpp|63|undefined reference to `__imp____glewCompileShader'|
main.cpp|65|undefined reference to `__imp____glewCreateProgram'|
main.cpp|66|undefined reference to `__imp____glewAttachShader'|
main.cpp|67|undefined reference to `__imp____glewAttachShader'|
main.cpp|68|undefined reference to `__imp____glewLinkProgram'|
main.cpp|70|undefined reference to `__imp____glewUseProgram'|
obj\Debug\glew.o||In function `glewContextInit':|
glew.c|6234|undefined reference to `__imp__glewExperimental'|
glew.c|6237|undefined reference to `__imp__glewExperimental'|
glew.c|6240|undefined reference to `__imp__glewExperimental'|
glew.c|6243|undefined reference to `__imp__glewExperimental'|
glew.c|6246|undefined reference to `__imp__glewExperimental'|
obj\Debug\glew.o:glew.c|6249|more undefined references to `__imp__glewExperimental' follow|
||=== Build finished: 18 errors, 0 warnings ===|
This does not make much sense to me. My best guess is that you're not compiling glew.c in with your project. Can you provide the total source (keep it minimal, like just main and initShader) and provide the command or steps you're using to compile/link this program? It should look something like
Code:
g++ main.c glew.c -o test -Ipath/glew/include -lopengl32 -lsomeWindowsLibThatCreatesContext
IGTHORN wrote:
Secondly, I need to learn a shitload more about the linker and compiling in c++.
When I see people start out in C++, the learning curve is so steep that I'll find them using things without really understanding what they even do. I did this too (and I continue to do this), since it's easy to get things to work if you just follow how other people do it. It's as if these things are a ritual one must perform to make things magically work. Well, this sucks when things don't go your way and there's no guide to follow.
I think that at some point you need to decide whether you want to do this kind of stuff for a career. If yes, it's worth your time to read manuals, purchase books (even outside of school), understand how the OS works, learn assembly, design and implement your own language/compiler, reimplement lots of things so that you can gain a powerful understanding of all the inner workings.
If you're not interested in all the computing details and just want to do the game dev, I would highly recommend you choose a different set of tools. C++ does not become your best friend until you've spent some quality time together.
What really worries me is that you're trying to jump into the world of shaders and programming the GPU, but your stumped on linking libraries together. It's like you enjoy pain :D
Here are some tips:
During the compile step you can get errors that go like "something is not declared". The compiler is telling you that you're trying to make it use things that you've never provided any information about. This commonly means you're missing a forward declaration (and by extension, you may be missing a header). In your case, your outdated gl.h header was missing the shader functions.
During the link step you may get errors about "unresolved symbols", where the symbol looks weird, but parts of it you may recognize from your code. The compiler must mangle the names according to a calling convention when placing the code into an object file. The linker will look over these object files during the link step and ensure that there is a definition for each symbol used. If one is missing, it spits out the error message that you see. Your
initShader function is compiled using the default C++ calling convention. Since C++ supports function overloading, and therefore multiple "initShader" symbols may exist, it must uniquely name it according to its function signature (and it may use other things) to arrive at the symbol "_Z10initShaderv". The GLEW functions you're using are mangled using the C call convention, where overloading does not exist, so they look more like they do in the C source: "__imp____glewCreateShader". I don't know where the "__imp__" prefix comes from, since when I compile glew.c it provides just "__glewCreateShader" (gcc (GCC) 4.4.0 20090526 (prerelease), Linux). I'm hoping someone else can chime in on this one. Compile just the glew.c into a glew.o object file and search it for the symbol "__imp____glewCreateShader". The case may be that you find a glewCreateShader symbol, but it doesn't look exactly the same. This would mean there's an inconsistency with how the compiler is to mangle the names somewhere.
(sorry, didn't mean for these to be so lengthy)
wyrmmage wrote:
ya, you need cygwin, because it's relying on the conf utility to actually generate a makefile for you. Cygwin isn't too hard to install, and it's pretty nice to have, so it might be worth a shot
I think this system is totally s***. It's not unix, it's windows. They should provide a windows way to compile (aside from visual studio), not require some unix environment.
theraje wrote:
Alternatively, look into GLee. It worked much better for me where I couldn't get GLEW to work.
I think that you should take a look at GLEE only after you successfully get GLEW working :)