There's an OpenGL project I have to work on for a course I am attending.
There were link errors due to GLEW. After some research, I found out that on OSX GLEW is not necessary.
I included following headers.
//#include "CL/cl_gl.h"
#include <OpenGL/glu.h>
#include <OpenGL/gl.h>
//#include <OpenGL/glext.h>
//#include <GLUT/glut.h>
But I am still getting compile errors of following kind:
use of undeclared identifier 'GL_TEXTURE_BUFFER_EXT'
glBindTexture(GL_TEXTURE_BUFFER_EXT, 0);
^
Where on OSX is the GLenum GL_TEXTURE_BUFFER_EXT resp. GL_TEXTURE_BUFFER defined?
The EXT variant will only be defined in glext.h or the headers which come or are generated by the various GL extenstion loaders. The actual GL_TEXTURE_BUFFER enum is defined in OpenGL/gl3.h. On OSX, modern GL is part of the OS, and you can directly link the modern GL funtions. However, I would still recommend using some GL loader, just for portability reasons.
Related
I'm opening an OpenGL context using SDL in OSX 10.8.5.
I've already run some tutorials that draw lines/triangles etc. I then started trying the more modern tutorials at www.open.gl
I'm running into trouble with the OpenGL 3+ API. I already include gl3.h in my headers:
#include <SDL2/SDL.h>
#include <SDL2/SDL_opengl.h>
#include <OpenGL/gl3.h>
I get a warning, which is expected since I think the sdl headers open gl.h. That's okay, but the problem is that the but the compiler still reports that glGenVertexArrays as undefined even though gl3.h is included, saying error: use of undeclared identifier 'glGenVertexArrays' glGenVertexArrays(1, &vao);
I believe I've seen this problem myself. I had to add an ifdef statement in one of my headers
#ifdef __APPLE__
#define glGenVertexArrays glGenVertexArraysAPPLE
#define glBindVertexArray glBindVertexArrayAPPLE
#define glDeleteVertexArrays glDeleteVertexArraysAPPLE
#endif
Also, you should be including either the SDL OpenGL header or the native system header. However, if you want to use the SDL OpenGL header, you should problaby do it like this
#define GL_GLEXT_PROTOTYPES 1
#include <SDL2/SDL_opengl.h>
or you'll only get the older OpenGL 1.x functions.
You don't have to include SDL_opengl.h, just include :
#ifdef __APPLE__
#include <OpenGL/gl3.h>
#include <OpenGL/gl3ext.h>
#endif
I'm using C++ and Opengl, and I'm trying to use SOIL, but when I compile, I get undefined reference to glBindTexture, glTexImage2D, etc. However, this is only coming from SOIL.c, not my own source code. This is what the error produces:
http://pastebin.com/sKrQaBhz
My graphics card is NVIDIA GeForce GTX 680 and my drivers are fully updated. I have everything linked and I'm using premake to manage my project. I'm developing on a linux machine, however, I'm trying to cross compile it onto my windows machine, which gives this error. If I compile it on linux, it's completely fine. This is my premake4.lua file:
http://pastebin.com/T4hsbdz0
My include files is this:
#include "opengl/gl_core_3_3.hpp"
#include <GLFW/glfw3.h>
#include <SOIL/SOIL.h>
#include <glm/glm.hpp>
#include <glm/gtx/transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <iostream>
#include <cstdio>
#include <cstdlib>
#include "loadshader.hpp"
I'm using mingw32 to compile my code. Before I was using SOIL, everything was fine. I downloaded SOIL from their webpage at lonesock.net, which I then copied over the libSOIL.a and their include files, but it just doesn't work.
Links order matters for g++.
Try this order:
links { "SOIL", "glfw3", "opengl32", "gdi32", "glu32" }
(edit: fixed the OP answer according to the duplicated question in Premake forum: http://industriousone.com/topic/how-use-premake-compile-static-library)
Looking at SOIL homepage, they said that it must be linked staticly. So, instead of using dynamic linking ('-l' in gcc compiler), try to specify the full path of the library.
This post illustrate what I want to say: https://stackoverflow.com/a/4156190/2293156
gcc -lsome_dynamic_lib some_static_lib.a code.c
I’m currently working on a final programming project for a games development course, and chose to make use of C++ and OpenGL for the 3D rendering side of the program (despite the fact I have little experience with it).
I was working with it until now absolutely fine with no serious errors, and then left it for a few days. But when I returned I started to get various "C4430 - Missing Type Specifier" errors with the few GLfloat variables I had used.
This was my previous definitions, which worked fine until I reloaded today:
#include <gl/glew.h>
#include <gl/glut.h>
... Other variable and object definitions
const GLfloat DEFAULT_X = -5.0f; //C4430: missing type specifyer on all 3 lines and
const Glfloat DEFAULT_Y = -4.0f; //C2146: syntax error : missing ';' before identifier 'DEFAULT_Y' on this line only
const GLfloat DEFAULT_Z = -20.0f;
GLfloat viewX = DEFAULT_X; //This line is fine
GLfloat viewY = DEFALUT_Y; //Resulting C2065: Undeclared identifyer
GLfloat viewZ = DEFALUT_Z; //on both these lines
In an attempt to fix this I began altering the #includes (perhaps, a daft approach, but I was pretty confused at this point) and found that adding Windows.h and gl/GL.h, as some have suggested, fixed all but one of the problems.
#include <Windows.h>
#include <gl/GL.h>
#include <gl/glew.h>
#include <gl/glut.h>
The new problem is that attempting to use gl/GL.h before gl/glew.h throws the error "C1189: gl.h included before glew.h" because, at a guess, glew includes gl.h itself. But any alteration brings back the previous type specifyer errors.
What's confusing me is that if glew was including GL.h, then wouldn’t these type specifiers have also been included? I’m going to continue method coding what I can without testing for the time being, but need to be able to test what I’m doing soon. Can anyone offer help or suggestions?
#include <Windows.h>
#include <gl/GL.h>
#include <gl/glut.h>
#include <gl/glew.h>
This is the wrong order to include these headers in.
GLEW (or whatever OpenGL loader you're using) always comes first. You never include gl.h with an OpenGL loader headers; you just include theirs (glew.h in this case). And it comes before all other headers for OpenGL or OpenGL tools.
FreeGLUT's headers come next. After that... you shouldn't be including window.h at all, unless you're doing some Windows-specific code. If you are, you include it after FreeGLUT's stuff.
I'm working on an OpenGL program to test out shaders and trying to compile them. However, the call to glCreateShader() (and other shader calls like glDeleteShader) give the following error:
(this error is from glCreateShader())
Error 3 error LNK2001: unresolved external symbol _pglCreateShader
I'm using Visual Studio 2012 and on windows 7. Got one of the latest nvidia cards including the latest drivers so can't be my OpenGL version.
I'm using the glTools header files for all the helper functions for the OpenGL Superbible 4th edition. Not sure if there is an error in using these files?
I'll post my includes in case this could be of any help as well.
#pragma once
#include <Windows.h>
// Basic C++ includes
#include <stdio.h>
#include <tchar.h>
#include <iostream>
#include <string>
#include <sstream>
#include <fstream>
#include <vector>
using namespace std;
// OpenGL specific and GUI includes
#include "shared/gltools.h"
#include "shared/math3d.h"
#include <SOIL.h>
And linker options:
soil.lib;opengl32.lib;gltools.lib;
Oké, the problem has been solved thanks to the answers:
I edited my glTools.h to include 'gl/glew.h' instead of "glee.h", added a ;glew32.lib option to my linker and added glewInit() before entering the main loop. I've also added the GLEW libs,dlls and includes into the appropriate folder and all the functions work like they should! :)
Grab a copy of GLEW to handle extension loading.
Doing it by hand is...annoying.
On Windows, you use WGL, and when using WGL you can't just link against the GL functions directly. All the functions you get are these; you're supposed to dynamically grab the pointer to the GL entry point you want with wglGetProcAddress (as in here) before you can use them.
Basically, OpenGL on Windows is a PITA if you do the GL entrypoint function pointer loading manually. It's much easier to use a utility library to grab the pointers for you, such as GLEW.
I am trying to get protobuf into xcode 4 and work with ios 5. I've done other tutorials none have worked. I have used a script to compile the libraries into arm 7 architecture and then added them to my project. This is the only thing that has worked so far.
My issue now is that I am trying to use the c++ generated files; however, I am getting an error saying #include -> lexical or preprocessor issue.
Any tips? It only showed this when I tried to run my project on the ipad. Before, it was fine with it.
Thanks. :)
// Generated by the protocol buffer compiler. DO NOT EDIT!
// source: addressbook.proto
#ifndef PROTOBUF_addressbook_2eproto__INCLUDED
#define PROTOBUF_addressbook_2eproto__INCLUDED
#include <string>
#include <google/protobuf/stubs/common.h>
//#include "google/protobuf/stubs/common.h"
#if GOOGLE_PROTOBUF_VERSION < 2004000
#error This file was generated by a newer version of protoc which is
#error incompatible with your Protocol Buffer headers. Please update
#error your headers.
#endif
#if 2004001 < GOOGLE_PROTOBUF_MIN_PROTOC_VERSION
#error This file was generated by an older version of protoc which is
#error incompatible with your Protocol Buffer headers. Please
#error regenerate this file with a newer version of protoc.
#endif
#include <google/protobuf/generated_message_util.h>
#include <google/protobuf/repeated_field.h>
#include <google/protobuf/extension_set.h>
#include <google/protobuf/generated_message_reflection.h>
Update: This only breaks when I include it in an obj c file. I can make a Demo.h and include addressbook. Why can't I include addressbook.pb.h into an obj c file? Am I missing a setting somewhere? Which one?