Not my homework, just doing this on the side. You built a solution using MSVS, I have always been able to run off of MSVS, I am looking to use gcc. If I was taking a class in opengl there is no way in hell I would use gcc, I would go MSVS all the way because it works and everyone tells me it's the best. I first went down this road because of my instructor, but know I just want to know what the hell is going on.

[attachment=20661:4mad3u5-CB.zip]

Code::Blocks will display the command line while compiling, there you go...

Bregma, on 26 Mar 2014 - 2:15 PM, said:

I think the header files may be set up to build under MSVC, so the #ifdefs may be set incorrectly. What if you add -DGLAPI to the command line?

When I did that I got this but I don't know how to send all my errors to a file. I know how to use fprint in c to send output to a file but I don't know about errors:

I googled how to redirect stderr and stdout in the DOS command line for you. I'm not sure if you're using the DOS command line or a POSIX-style shell (like MinGW32), but either way they're the same: >out.log 2>&1. You put that at then end of your compile command to capture the diagnostics. Can be a lifesaver.

From your description I really suspect there is a different set of predefined macros supplied by the different compilers, and that some header file is making an invalid assumption about the meaning of them. You plan of attack should be to grep (search) through all of the header files to find one (or more) line(s) where GLAPI is #defined, then figure out which combination of macros is required to get it defined correctly. It is normal for different compilers to have different sets of predefined macros; it's one of the things that makes preprocessing actually useful.

You can get a list of predefined macros from GCC using the -dM switch (from the GCC manual: touch foo.h; cpp -dM foo.h). I seem to recall MSVC has a similar thing. I suspect the culprit may be something like #ifdef _WIN32 used incorrectly (but don't quote me on the macro, it's just an example).

Good luck.

Hey, thank you so much man.

Not my homework, just doing this on the side. You built a solution using MSVS, I have always been able to run off of MSVS, I am looking to use gcc. If I was taking a class in opengl there is no way in hell I would use gcc, I would go MSVS all the way because it works and everyone tells me it's the best. I first went down this road because of my instructor, but know I just want to know what the hell is going on.

4mad3u5-CB.zip

Code::Blocks will display the command line while compiling, there you go...

If that works I really appreciate it, thank you.

Not my homework, just doing this on the side. You built a solution using MSVS, I have always been able to run off of MSVS, I am looking to use gcc. If I was taking a class in opengl there is no way in hell I would use gcc, I would go MSVS all the way because it works and everyone tells me it's the best. I first went down this road because of my instructor, but know I just want to know what the hell is going on.

4mad3u5-CB.zip

Code::Blocks will display the command line while compiling, there you go...

Just tested this with the program from your other thread. Worked fine after I changed the include section to this:

#include <windows.h>
#include <GLTools.h> // OpenGL toolkit
#include <GLShaderManager.h> // Shader Manager Class
#include <GL/glut.h> // Windows FreeGlut equivalent

Now for the *ACTUAL* diagnosis.

1) The preprocessor was doing its job just fine. As expected from software that is extensively tested before release, and runs on thousands of machines every single day.

2) GLTools is a library in its own right and bundles GLEW, therefore there was no need to link against GLEW. But it was necessary to link against GLTools, or referring to *ALL* compiled object files from GLTools while compiling anything that depended on it - hint, that's what libraries are good for.

3) In order to compile Triangle.cpp it was necessary to define FREEGLUT_STATIC, otherwise you'd get an error in freeglut-2.6.0\include\GL\freeglut_std.h.

Not my homework, just doing this on the side. You built a solution using MSVS, I have always been able to run off of MSVS, I am looking to use gcc. If I was taking a class in opengl there is no way in hell I would use gcc, I would go MSVS all the way because it works and everyone tells me it's the best. I first went down this road because of my instructor, but know I just want to know what the hell is going on.

4mad3u5-CB.zip

Code::Blocks will display the command line while compiling, there you go...

Just tested this with the program from your other thread. Worked fine after I changed the include section to this:

#include <windows.h>
#include <GLTools.h> // OpenGL toolkit
#include <GLShaderManager.h> // Shader Manager Class
#include <GL/glut.h> // Windows FreeGlut equivalent

Now for the *ACTUAL* diagnosis.

1) The preprocessor was doing its job just fine. As expected from software that is extensively tested before release, and runs on thousands of machines every single day.

2) GLTools is a library in its own right and bundles GLEW, therefore there was no need to link against GLEW. But it was necessary to link against GLTools, or referring to *ALL* compiled object files from GLTools while compiling anything that depended on it - hint, that's what libraries are good for.

3) In order to compile Triangle.cpp it was necessary to define FREEGLUT_STATIC, otherwise you'd get an error in freeglut-2.6.0\include\GL\freeglut_std.h.

The second program is from Opengl programming guide so it doesn't use the GLTools library, but it's probably just using the GLEW.

Not my homework, just doing this on the side. You built a solution using MSVS, I have always been able to run off of MSVS, I am looking to use gcc. If I was taking a class in opengl there is no way in hell I would use gcc, I would go MSVS all the way because it works and everyone tells me it's the best. I first went down this road because of my instructor, but know I just want to know what the hell is going on.

4mad3u5-CB.zip

Code::Blocks will display the command line while compiling, there you go...

Just tested this with the program from your other thread. Worked fine after I changed the include section to this:

#include <windows.h>
#include <GLTools.h> // OpenGL toolkit
#include <GLShaderManager.h> // Shader Manager Class
#include <GL/glut.h> // Windows FreeGlut equivalent

Now for the *ACTUAL* diagnosis.

1) The preprocessor was doing its job just fine. As expected from software that is extensively tested before release, and runs on thousands of machines every single day.

2) GLTools is a library in its own right and bundles GLEW, therefore there was no need to link against GLEW. But it was necessary to link against GLTools, or referring to *ALL* compiled object files from GLTools while compiling anything that depended on it - hint, that's what libraries are good for.

3) In order to compile Triangle.cpp it was necessary to define FREEGLUT_STATIC, otherwise you'd get an error in freeglut-2.6.0\include\GL\freeglut_std.h.

But it was a preprocessor error so my teacher was correct. I never said the preprocessor wasn't doing what it was suppose to be doing I said there was a preprocessor error and it was, a redefinition and it's the preprocessor's job to see that. Whoever voted down is an idiot.

But it was a preprocessor error so my teacher was correct. I never said the preprocessor wasn't doing what it was suppose to be doing I said there was a preprocessor error and it was, a redefinition and it's the preprocessor's job to see that. Whoever voted down is an idiot.

Preprocessor error. Yeah, right.

Let's keep the include section untouched, and try to build Triangle.cpp sans linking with the GLTools library... I'll cut you some slack and compile ..\Common\InitShader.cpp as well, since Triangle.cpp depends on it.

Guess what? THE BUILD FAILS. The object files WON'T LINK with the static libraries available for download (libfreeglut.a and libglew32.a).

-------------- Build: Debug in Triangle (compiler: GNU GCC Compiler)---------------

g++.exe -Wall -DFREEGLUT_STATIC -g -std=c++11 -m32 -I..\GLTools\include -I..\include -c C:\4mad3u5-CB\Common\InitShader.cpp -o obj\Debug\Common\InitShader.o
g++.exe -Wall -DFREEGLUT_STATIC -g -std=c++11 -m32 -I..\GLTools\include -I..\include -c C:\4mad3u5-CB\Triangle\Triangle.cpp -o obj\Debug\Triangle.o
g++.exe -o bin\Debug\Triangle.exe obj\Debug\Common\InitShader.o obj\Debug\Triangle.o -m32 ..\lib\windows\libglew32.a ..\lib\windows\libfreeglut.a -lopengl32 -lwinmm -lgdi32
In file included from ..\include/Angel.h:67:0,
from C:\4mad3u5-CB\Common\InitShader.cpp:2:
..\include/vec.h: In constructor 'Angel::vec4::vec4(const Angel::vec3&, float)':
..\include/vec.h:325:5: warning: 'Angel::vec4::w' is initialized with itself [-Winit-self]
vec4( const vec3& v, const float s = 1.0 ) : w(w)
^
obj\Debug\Common\InitShader.o: In function `ZN5Angel10InitShaderEPKcS1_':
C:/4mad3u5-CB/Common/InitShader.cpp:41: undefined reference to `_imp____glewCreateProgram'
C:/4mad3u5-CB/Common/InitShader.cpp:51: undefined reference to `_imp____glewCreateShader'
C:/4mad3u5-CB/Common/InitShader.cpp:52: undefined reference to `_imp____glewShaderSource'
C:/4mad3u5-CB/Common/InitShader.cpp:53: undefined reference to `_imp____glewCompileShader'
C:/4mad3u5-CB/Common/InitShader.cpp:56: undefined reference to `_imp____glewGetShaderiv'
C:/4mad3u5-CB/Common/InitShader.cpp:60: undefined reference to `_imp____glewGetShaderiv'
C:/4mad3u5-CB/Common/InitShader.cpp:62: undefined reference to `_imp____glewGetShaderInfoLog'
C:/4mad3u5-CB/Common/InitShader.cpp:71: undefined reference to `_imp____glewAttachShader'
C:/4mad3u5-CB/Common/InitShader.cpp:75: undefined reference to `_imp____glewLinkProgram'
C:/4mad3u5-CB/Common/InitShader.cpp:78: undefined reference to `_imp____glewGetProgramiv'
C:/4mad3u5-CB/Common/InitShader.cpp:82: undefined reference to `_imp____glewGetProgramiv'
C:/4mad3u5-CB/Common/InitShader.cpp:84: undefined reference to `_imp____glewGetProgramInfoLog'
C:/4mad3u5-CB/Common/InitShader.cpp:92: undefined reference to `_imp____glewUseProgram'
obj\Debug\Triangle.o: In function `Z7SetupRCv':
C:/4mad3u5-CB/Triangle/Triangle.cpp:29: undefined reference to `GLShaderManager::InitializeStockShaders()'
C:/4mad3u5-CB/Triangle/Triangle.cpp:37: undefined reference to `GLBatch::Begin(unsigned int, unsigned int, unsigned int)'
C:/4mad3u5-CB/Triangle/Triangle.cpp:39: undefined reference to `GLBatch::End()'
obj\Debug\Triangle.o: In function `Z11RenderScenev':
C:/4mad3u5-CB/Triangle/Triangle.cpp:52: undefined reference to `GLShaderManager::UseStockShader(GLT_STOCK_SHADER, ...)'
C:/4mad3u5-CB/Triangle/Triangle.cpp:53: undefined reference to `GLBatch::Draw()'
obj\Debug\Triangle.o: In function `main':
C:/4mad3u5-CB/Triangle/Triangle.cpp:64: undefined reference to `gltSetWorkingDirectory(char const*)'
obj\Debug\Triangle.o: In function `_tcf_0':
C:/4mad3u5-CB/Triangle/Triangle.cpp:9: undefined reference to `GLBatch::~GLBatch()'
obj\Debug\Triangle.o: In function `_tcf_1':
C:/4mad3u5-CB/Triangle/Triangle.cpp:10: undefined reference to `GLShaderManager::~GLShaderManager()'
obj\Debug\Triangle.o: In function `_static_initialization_and_destruction_0':
C:/4mad3u5-CB/Triangle/Triangle.cpp:9: undefined reference to `GLBatch::GLBatch()'
C:/4mad3u5-CB/Triangle/Triangle.cpp:10: undefined reference to `GLShaderManager::GLShaderManager()'
obj\Debug\Triangle.o: In function `ZN7GLBatch16CopyVertexData3fEPf':
C:\4mad3u5-CB\Triangle/../GLTools/include/GLBatch.h:89: undefined reference to `GLBatch::CopyVertexData3f(float (*) [3])'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 1 second(s))
24 error(s), 1 warning(s) (0 minute(s), 1 second(s))

Isn't it obvious? Even if you sorted out the order of the included headers, your program WOULD NEVER LINK. Also, the preprocessor has NO BUSINESS handling redefinitions. Think about it: when the preprocessor sees a new definition for a symbol it already parsed, what should it do, keep the old definition, or the new one? The preprocessor's job is to POINT OUT such problems, and it's YOUR JOB to avoid such USER ERRORS (hint: read about include guards and #pragma once).

Whoever downvoted you is not an idiot. YOU are an idiot. Your teacher was simply wrong, that happens. You, on the other hand, are MUCH worse than that, because even when faced with HARD EVIDENCE of your errors you insist on doing all you can to twist the facts and look like you are not clueless. NOBODY is right 100% of the time.

PLEASE take the time to thoroughly read How To Ask Questions The Smart Way. If you're the TL;DR kind of person, at the very least read the On Not Reacting Like A Loser section.

But it was a preprocessor error so my teacher was correct. I never said the preprocessor wasn't doing what it was suppose to be doing I said there was a preprocessor error and it was, a redefinition and it's the preprocessor's job to see that. Whoever voted down is an idiot.

Preprocessor error. Yeah, right.

Let's keep the include section untouched, and try to build Triangle.cpp sans linking with the GLTools library... I'll cut you some slack and compile ..\Common\InitShader.cpp as well, since Triangle.cpp depends on it.

Guess what? THE BUILD FAILS. The object files WON'T LINK with the static libraries available for download (libfreeglut.a and libglew32.a).

-------------- Build: Debug in Triangle (compiler: GNU GCC Compiler)---------------

g++.exe -Wall -DFREEGLUT_STATIC -g -std=c++11 -m32 -I..\GLTools\include -I..\include -c C:\4mad3u5-CB\Common\InitShader.cpp -o obj\Debug\Common\InitShader.o
g++.exe -Wall -DFREEGLUT_STATIC -g -std=c++11 -m32 -I..\GLTools\include -I..\include -c C:\4mad3u5-CB\Triangle\Triangle.cpp -o obj\Debug\Triangle.o
g++.exe -o bin\Debug\Triangle.exe obj\Debug\Common\InitShader.o obj\Debug\Triangle.o -m32 ..\lib\windows\libglew32.a ..\lib\windows\libfreeglut.a -lopengl32 -lwinmm -lgdi32
In file included from ..\include/Angel.h:67:0,
from C:\4mad3u5-CB\Common\InitShader.cpp:2:
..\include/vec.h: In constructor 'Angel::vec4::vec4(const Angel::vec3&, float)':
..\include/vec.h:325:5: warning: 'Angel::vec4::w' is initialized with itself [-Winit-self]
vec4( const vec3& v, const float s = 1.0 ) : w(w)
^
obj\Debug\Common\InitShader.o: In function `ZN5Angel10InitShaderEPKcS1_':
C:/4mad3u5-CB/Common/InitShader.cpp:41: undefined reference to `_imp____glewCreateProgram'
C:/4mad3u5-CB/Common/InitShader.cpp:51: undefined reference to `_imp____glewCreateShader'
C:/4mad3u5-CB/Common/InitShader.cpp:52: undefined reference to `_imp____glewShaderSource'
C:/4mad3u5-CB/Common/InitShader.cpp:53: undefined reference to `_imp____glewCompileShader'
C:/4mad3u5-CB/Common/InitShader.cpp:56: undefined reference to `_imp____glewGetShaderiv'
C:/4mad3u5-CB/Common/InitShader.cpp:60: undefined reference to `_imp____glewGetShaderiv'
C:/4mad3u5-CB/Common/InitShader.cpp:62: undefined reference to `_imp____glewGetShaderInfoLog'
C:/4mad3u5-CB/Common/InitShader.cpp:71: undefined reference to `_imp____glewAttachShader'
C:/4mad3u5-CB/Common/InitShader.cpp:75: undefined reference to `_imp____glewLinkProgram'
C:/4mad3u5-CB/Common/InitShader.cpp:78: undefined reference to `_imp____glewGetProgramiv'
C:/4mad3u5-CB/Common/InitShader.cpp:82: undefined reference to `_imp____glewGetProgramiv'
C:/4mad3u5-CB/Common/InitShader.cpp:84: undefined reference to `_imp____glewGetProgramInfoLog'
C:/4mad3u5-CB/Common/InitShader.cpp:92: undefined reference to `_imp____glewUseProgram'
obj\Debug\Triangle.o: In function `Z7SetupRCv':
C:/4mad3u5-CB/Triangle/Triangle.cpp:29: undefined reference to `GLShaderManager::InitializeStockShaders()'
C:/4mad3u5-CB/Triangle/Triangle.cpp:37: undefined reference to `GLBatch::Begin(unsigned int, unsigned int, unsigned int)'
C:/4mad3u5-CB/Triangle/Triangle.cpp:39: undefined reference to `GLBatch::End()'
obj\Debug\Triangle.o: In function `Z11RenderScenev':
C:/4mad3u5-CB/Triangle/Triangle.cpp:52: undefined reference to `GLShaderManager::UseStockShader(GLT_STOCK_SHADER, ...)'
C:/4mad3u5-CB/Triangle/Triangle.cpp:53: undefined reference to `GLBatch::Draw()'
obj\Debug\Triangle.o: In function `main':
C:/4mad3u5-CB/Triangle/Triangle.cpp:64: undefined reference to `gltSetWorkingDirectory(char const*)'
obj\Debug\Triangle.o: In function `_tcf_0':
C:/4mad3u5-CB/Triangle/Triangle.cpp:9: undefined reference to `GLBatch::~GLBatch()'
obj\Debug\Triangle.o: In function `_tcf_1':
C:/4mad3u5-CB/Triangle/Triangle.cpp:10: undefined reference to `GLShaderManager::~GLShaderManager()'
obj\Debug\Triangle.o: In function `_static_initialization_and_destruction_0':
C:/4mad3u5-CB/Triangle/Triangle.cpp:9: undefined reference to `GLBatch::GLBatch()'
C:/4mad3u5-CB/Triangle/Triangle.cpp:10: undefined reference to `GLShaderManager::GLShaderManager()'
obj\Debug\Triangle.o: In function `ZN7GLBatch16CopyVertexData3fEPf':
C:\4mad3u5-CB\Triangle/../GLTools/include/GLBatch.h:89: undefined reference to `GLBatch::CopyVertexData3f(float (*) [3])'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 1 second(s))
24 error(s), 1 warning(s) (0 minute(s), 1 second(s))

Isn't it obvious? Even if you sorted out the order of the included headers, your program WOULD NEVER LINK. Also, the preprocessor has NO BUSINESS handling redefinitions. Think about it: when the preprocessor sees a new definition for a symbol it already parsed, what should it do, keep the old definition, or the new one? The preprocessor's job is to POINT OUT such problems, and it's YOUR JOB to avoid such USER ERRORS (hint: read about include guards and #pragma once).

Whoever downvoted you is not an idiot. YOU are an idiot. Your teacher was simply wrong, that happens. You, on the other hand, are MUCH worse than that, because even when faced with HARD EVIDENCE of your errors you insist on doing all you can to twist the facts and look like you are not clueless. NOBODY is right 100% of the time.

PLEASE take the time to thoroughly read How To Ask Questions The Smart Way. If you're the TL;DR kind of person, at the very least read the On Not Reacting Like A Loser section.

The first part was sorting out the included headers, that's why it was a preprocessor error.