While developing Raspberry Pi library compiled by g++4.9.2 I have met compability issue between boost (1.6.2) and ImageMagick++ API (7.0). When compiling this code:
#include <Magick++.h>
#include <boost/filesystem.hpp>
#include <boost/foreach.hpp>
I got these boost errors:
__assert_fail was not declared in this scope (path_trails.hpp)
...
__assert_fail was not declared in this scope (path.hpp)
...
__assert_fail was not declared in this scope (shared_ptr.hpp)
When deleting #include <Magick++.h> line everything runs fine. Unfortunately I need boost and ImageMagick as well in this source file. How to solve this issue?
A simple workaround is to include Magick++.h after boost.
#include <boost/filesystem.hpp>
#include <boost/foreach.hpp>
#include <Magick++.h>
I don't have a proper explanation for this problem but it seems to come from a clash when using different headers including assert.h (I had the same problem using the assimp library and ImageMagick) but I don't get why the order matters.
Reproducing your case, assert.h is included in:
cassert for boost
MagickCore/pixel-accessor.h for Magick++.h
If someone has an explanation for this problem feel free to edit.
Related
I can not use the function putText. I get the compilation error "putText is not member of CV" or "putText is not declared in this scope".
These are the libraries I am including:
#include <iostream>
#include "core.hpp"
#include "highgui.hpp"
#include "imgcodecs.hpp"
#include "cv.h"
and that's how I am calling it:
cv::putText(frame,"REC",Point(0,60),2,2,Scalar(0,0,255));
what am I doing wrong?
putText has been moved to imgproc module in OpenCV 3 (previously it was in core module).
So you need to:
#include "imgproc.hpp"
You can include opencv.hpp to avoid this kind of problems, since it will include all headers for you.
This problem has been already asked but after an extensive search on Google I've found no questions related to the 1.2.15 version of SDL with the last version of XCODE so please allow me to post the problem (again) and the solution I've found for those up-to-date version (30th September 2015).
Config:
OSX 10.10.5
XCODE 7.0
SDL 1.2.15
How to reproduce:
Copied the SDL.Framework to /Library/Frameworks as explained on the readme.txt
On XCODE Template > Building settings > Framework Search path as /Library/Frameworks
I included the SDL framework on the main.cpp file as follows:
#include <SDL/SDL.h>
When I try to compile and test I get an error because of a double declaration of class main...
This is the error message:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
(maybe you meant: _SDL_main)
This how I solved it:
I checked and saw that SDL.h is including all the following files:
#include "SDL_main.h"
#include "SDL_stdinc.h"
#include "SDL_audio.h"
#include "SDL_cdrom.h"
#include "SDL_cpuinfo.h"
#include "SDL_endian.h"
#include "SDL_error.h"
#include "SDL_events.h"
#include "SDL_loadso.h"
#include "SDL_mutex.h"
#include "SDL_rwops.h"
#include "SDL_thread.h"
#include "SDL_timer.h"
#include "SDL_video.h"
#include "SDL_version.h"
#include "begin_code.h"
One of them is SDL_main.h and on that file we see:
#define main SDL_main
This line is producing a conflict with the class main on main.cpp, commenting that line on SDL_main.h or commenting the line #include "SDL_main.h" on SDL.h solves the issue. I'm a noob on C++ (I just learn it at University many years ago) but from other languages I know that "hacking" a library is a very bad practice... though it seems to be a particular compatibility problem with MAXOSX and I really want to use XCODE...
Please correct and comment, justify yes or no, as I'm on a learning process.
Cheers!
I've resolved the problem with #undef main before the declaration of the main function.
my name is Ulrich and I just started writing my bachelor thesis, which includes a part where i write a program, which needs a Singular Value Decompostion.
At first i need to say, English is my 2nd language and I'm totally new to programming. So please help me with easy words ;)
After some research, I found that Armadillo offers a good SVD()-function, which is based on the Lapack library, so I downloaded them both and tried to install them correctly, and I think i failed at that part:
So here is the relevant parts of my written code:
#include <iostream>
#include <vector>
#include <random>
#include <time.h>
#include <math.h>
#include <fstream>
#include <cmath>
#include <sstream>
#include <armadillo>
using namespace std;
using namespace arma;
mat A(N,2*N+1, fill::zeros); //the zeroess will be replaced later, don't worry i know a SVD of zeroes is stupid ;)
mat U;
mat V;
vec S=svd(A);
The compilation error is:
undefined reference to 'dgesdd_'
What I use:
Code Blocks with MinGW compiler (Probably latest version; I installed it 3 days ago).
Armadillo Library 4.650.4
Lapack Library 3.5.0
Windows 8.1
What I have done:
I linked in the settings of Codeblocks the compiler with the Folder containing a lot of .header files from Armadillo (.../include/armadillo_bits/)
and i linked in the same way the Lapack folder with 4 .header files(.../lapacke/include/)
Furthermore the readme from armadillo said I shall comment out certain lines from a file called config.hpp
i looked through the whole file, but i think i don't have to uncomment anything. but just in case you need to see it, I can upload the file for you.
PS: while searching for a solution I came across this question which looked quite similar to my problem and seems to be easy fixable, but unfortunately I don't understand anything of it:
Question from stackoverflow
i hope you can help me with this,
Ulli
I've been following Thrift C++ wiki tutorial. and everything works fine with TSimpleServer.
But, when I try to implement TNonblockingServer I'm getting this error :(
undefined reference to `apache::thrift::server::TNonblockingServer::serve()
undefined reference to `apache::thrift::server::TNonblockingServer::~TNonblockingServer()
I think its something related to the header files or the namespaces.
The following headers im using:
#include <thrift/protocol/TBinaryProtocol.h>
#include <thrift/server/TSimpleServer.h>
#include <thrift/transport/TServerSocket.h>
#include <thrift/transport/TBufferTransports.h>
#include <thrift/concurrency/ThreadManager.h>
#include <thrift/concurrency/PosixThreadFactory.h>
#include <thrift/server/TThreadedServer.h>
#include <thrift/server/TNonblockingServer.h>
using namespace ::apache::thrift;
using namespace ::apache::thrift::protocol;
using namespace ::apache::thrift::transport;
using namespace ::apache::thrift::server;
using namespace ::apache::thrift::concurrency;
any idea whats wrong?
I understand that this is really late reply.
It is due to missing libthriftnb library for TNonblockingServer.
while Tsimplesever and TThreadedServer are in libthrift library so it was works with you.
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.