I have two projects; a static library and an executable (standard Win32 setup, using the multithreaded debug dll setting for both).
In my libray, I have a Globals.h, with the following code:
#ifndef _GLOBALS_H
#define _GLOBALS_H
#include <SDL.h>
#include <string>
namespace Eng
{
bool Run = true;
SDL_Window *Window = NULL;
SDL_GLContext GlContext;
Uint32 WindowFlags = SDL_WINDOW_OPENGL;
}
#endif
This is all fine and dandy, and within that project everything works fine. However, as soon as I include that file within more than one file in my executable project (all protected by inclusion guards), I start getting multiply defined symbol errors for each variable within Globals.h.
As well, I'm getting quite a few macro redefinition warnings from math.h (M_PI macro redefinition). I'm not sure if this is linked, but it seems likely due to the similar nature of error (guards defined in one project seemingly not applying in the other).
Anyone have any ideas how to resolve this? I feel like I'm missing some vitally important compiler setting somewhere :(
Related
Some time ago I started a big header library in C++1x using XCode. The current layout of the library is () something like (partial output from ls -R sponf)
sponf/sponf:
ancestors sponf.h sponf_utilities.h
categories sponf_children.h utilities
children sponf_macros.h
sponf/sponf/ancestors:
function.h meter.h set.h simulation.h
sponf/sponf/categories:
free_space.h prng.h random_distribution.h series.h
sponf/sponf/children:
distributions histogram.h random simulations
meters numeric series spaces
sponf/sponf/children/distributions:
arcsine_der.h exponential.h
box_muller.h uniform.h
sponf/sponf/children/meters:
accumulator.h timer.h
#... other subdirs of 'children' ...
sponf/sponf/utilities:
common_math.h limits.h string_const.h
#... other directories ...
I wanted to port this project to CLion, which seems a really good IDE (based on the similar AndroidStudio IDE) but I'm getting some troubles.
Small test program
I tried this small program as a test:
#include <iostream>
#include <sponf/sponf.h>
using namespace std;
int main() {
using space = sponf::spaces::euclidean_free_space<double, 3>;
sponf::simulations::random_walk<space> rw;
rw.step(1);
std::cout << rw.position.value << std::endl;
return 0;
}
The program compiles and runs fine. However, CLion does not recognize the spaces namespace (declared in one of the children files), nor the simulations namespace; they are both marked red and I cannot inspect their content, nor navigate to their definitions by ⌘-clicking, etc. etc...
Relevant parts of the library
Looking in "sponf.h" we find
#ifndef sponf_h
#define sponf_h
/* The classes below are exported */
#pragma GCC visibility push(default)
// include some of the standard library files
// ...
#include <Eigen/Eigen>
#include "sponf_macros.h"
#include "sponf_utilities.h"
#include "sponf_children.h"
#pragma GCC visibility pop
#endif
while in "sponf_children.h" (which is located at the top level, next to "sponf.h") we find
#ifndef sponf_locp_sponf_children_h
#define sponf_locp_sponf_children_h
namespace sponf {
// include some of the children
// ...
#include "children/spaces/euclidean_free_space.h"
#include "children/simulations/random_walk.h"
// include remaining children
// ...
}
#endif
Each "child" header will then include its corresponding "ancestor" or "category" header (which defines the superclass of the "child" itself).
The reaction of CLion
Despite the autocompletition prediction, which easily finds all the subdirectories and the headers, all the include directives in this last file get marked red and ⌘-clicking on any of them leads to a popup message
Cannot find declaration to go to
while the right ribbon of the editor signal many errors like
',' or ) expected
) expected
Declarator expected
Expecting type
Missing ;
Unexpected symbol
which are not the same for each include statement (each generates from 2 to all of these errors).
On the other hand, CLion is perfectly able to find all Eigen headers, which have pretty much the same structure!
I have put both libs in /opt/local/include and changed CMakeLists.txt accordingly
cmake_minimum_required(VERSION 2.8.4)
project(sponf)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
include_directories(/opt/local/include/sponf /opt/local/include/eigen3)
set(SOURCE_FILES main.cpp)
add_executable(sponf ${SOURCE_FILES})
Why can't CLion properly parse the project structure? XCode, after having included /opt/local/include/sponf and /opt/local/include/eigen3 in the HEADER_SEARCH_PATHS env. variable of the project, is able to find any header while compiling the same exact program.
Is there anything else I need to know? Am I doing it wrong or is it that CLion isn't that mature yet and this is just a sorry bug? This is my first approach to the CLion and the CMake toolchain, so any kind of information about it will be greatly appreciated!
Sorry for the very long question, I didn't manage to shrink it further... Thanks in advance guys, see you soon!
Here what I did in windows using cigwin64. I wanted to use Eigen library include in my project.
Eigen library is places in /usr/include/eigen then edited CMakeLists.txt and add
include_directories("/usr/include/eigen")
into it. Now CLion can find all source files in eigen lib. May be this what you wanted too.
Downgrade to Clion 2016.1.4 fixes the problem
Error: cannot open source file "GL/glew.h"
I have the following code :
//Include GLEW
#include <GL/glew.h>
//Include GLFW
#include <GLFW/glfw3.h>
//Include the standard C++ headers
#include <stdio.h>
#include <stdlib.h>
//Define an error callback
static void error_callback(int error, const char* description)
{
...
I took from there: http://www.41post.com/5178/programming/opengl-configuring-glfw-and-glew-in-visual-cplusplus-express#part4
In order to have a somewhat portable solution, before I even started Visual Studio 2013 I created two System Environment Variable in windows.
GLEW=C:\Install\Development\C++\Framework\glew-1.10.0-win32\glew-1.10.0
GLFW=C:\Install\Development\C++\Framework\glfw-3.0.4.bin.WIN32\glfw-3.0.4.bin.WIN32
So in my project I could for instance write a additional include folder as: %GLEW%\include
As I said, it builds fine and runs fine as well.
Yet, not having intellisense behave properly is really annoying.
How to fix it?
My syntax was actually wrong, you cant use global environment variable in VS using %<name>% but you have to use $(%<name>).
Wherever I wrote %GLEW%\include I should have $(GLEW)\include.
It's working fine now.
Though I'm completely clueless why it built.
This post: https://stackoverflow.com/a/11543754/910813 got me to remind that.
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.
C++ newbie here. I'm trying to put some WIA functions in a DLL. I keep getting and undeclared identifier on the IWiaDevMgr variable. When creating the project I chose the Win32 Console Application and DLL application type. Not sure if it matters but I put the wiaguid.lib in the project
properties -> Linker -> input -> additional dependencies.
What is wrong with this code?
MyDLL.h
#include <wia.h>
namespace MyDLL
{
class MyFirstFuncs
{
public:
static __declspec(dllexport) int doWork();
};
}
MyDLL.cpp
#include "MyDLL.h"
namespace MyDLL
{
int MyFirstFuncs::doWork()
{
IWiaDevMgr *pIWiaDevMgr;
}
}
I had the exact same problem. Through trial and error I found that
#include <windows.h>
#include <wia.h>
fixed the problem.
I'm a C++ newbie also so couldn't tell you the exact reason why this works. Probably WIA is dependant on some definitions/macros/whatever in WINDOWS.H
Check the order in which you have included your header files. It may be the same problem like the one I had in programming a Directshow application. I had included vmr9.h before d3d9.h. During the build process, the compiler fired errors concerning d3d9 objects included in the vmr9.h. I had to reorder the inclusions to solve the problem
I have this very strange problem while compiling the project.
MOC seems to be adding a namespace to the class name being moc'ed, although it's not mentioned anywhere in the file/class.
The namespace, however, exists in a library which I use, but it's hidden far away in the header files and I don't use it in the UI files. This is what MOC generates:
const QMetaObject SmpTl::CaptureController::staticMetaObject = {
{ &QObject::staticMetaObject, qt_meta_stringdata_SmpTl__CaptureController,
qt_meta_data_SmpTl__CaptureController, 0 }};
The SmpTl namespace is not mentioned anywhere in the declaration of CaptureController, but it appears in the MOC-generated .cpp file.
I'm using Visual Studio with the QT integration.
I also ran into this problem. I had code that looked like this:
namespace foo {
#ifdef _WIN32
... // This code was fine
#else
#error Not Supported
#endif
}
This confused MOC into thinking namespace foo never closed. Apparently, it didn't know _WIN32 was defined, and got tripped up by the fact that I forgot to put quotes around the error message. Changing it to:
#error "Not Supported"
fixed my problem.
SmpTl is the namespace CaptureController is defined in, as it was found by MOC.
The Q_OBJECT macro expands into the declaration of the staticMetaObject-variable inside your class definition (among other things it expands into). The MOC-file contains the definition of that variable.
If this is not correct, please post your Qt version and a stripped down version of your header-file.