Compiling with g++ (from Makefile generated with qmake) using the line
#if !QT_CONFIG(printer)
// do something
#endif
gives a preprocessor error on both g++ (7.3.0)
test.cpp:25:6: error: division by zero in #if
#if !QT_CONFIG(printer)
and clang (6.00)
test.cpp:25:6: error: division by zero in preprocessor expression
#if !QT_CONFIG(printer)
^~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:84:30: note: expanded from macro 'QT_CONFIG'
#define QT_CONFIG(feature) (1/QT_FEATURE_##feature == 1)
~^~~~~~~~~~~~~~~~~~~~~
1 error generated.
where clang++ gives the more detailed output. printer is not enabled, thus the macro as recommended to do conditional compilation. The QT version is 5.9.5. Any suggestions (wrong usage?) appreciated.
I don't think you should focus on that macro. The point of that macro is to simply crash your compilation code when QT_FEATURE_printer is zero. The code was not designed to work otherwise.
Instead of using the macro conditionally try to find out why QT_FEATURE_printer is zero and include / configure dependencies to change that (it seems to be definend in printsupport/qtprintsupport-config.h).
This is what happens if you have updated your qt sources to something using a new feature without running configure again. When you run configure the new features are set.
This is fixed in Qt 5.12.3. The newer version of notepad.cpp begins:
#include <QFile>
#include <QFileDialog>
#include <QTextStream>
#include <QMessageBox>
#if defined(QT_PRINTSUPPORT_LIB)
#include <QtPrintSupport/qtprintsupportglobal.h>
#if QT_CONFIG(printer)
#if QT_CONFIG(printdialog)
#include <QPrintDialog>
#endif // QT_CONFIG(printdialog)
#include <QPrinter>
#endif // QT_CONFIG(printer)
#endif // QT_PRINTSUPPORT_LIB
#include <QFont>
#include <QFontDialog>
Related
I was trying to build OpenCV version 2.4.8 to use it with CodeBlocks and MinGw. I followed the instructions from here. But I got the following error. I have no clue how to solve it. I didn't find anything useful by searching in the net.
This is also not solving.
I don't want to mess with the openCV code, I intend to use OpenCV in my project and this is first time I am using it.
[ 26%] Built target pch_Generate_opencv_highgui
[ 26%] Building CXX object modules/highgui/CMakeFiles/opencv_highgui.dir/src/window_w32.cpp.obj
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp: In function 'void cvSetModeWindow_W32(const char*, double)':
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp:477: error: 'MonitorFromRect' was not declared in this scope
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp: In function 'LRESULT MainWindowProc(HWND__*, UINT, WPARAM, LPARAM)':
C:\Program Files (x86)\opencv\sources\modules\highgui\src\window_w32.cpp:1355: error: 'MonitorFromRect' was not declared in this scope
mingw32-make.exe[2]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/src/window_w32.cpp.obj] Error 1
mingw32-make.exe[1]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
I tried to manually include the prototype of the function in the file, but then it comes to linking error.
will anyone please tell me what may have gone wrong here? How can I solve it?
It seems All the changes from recent commit is not reflected in your check out. To resolve the problems, make the following changes:
In modules/highgui/src/precomp.hpp, add the + marked line:
#if defined WIN32 || defined WINCE
+ #if !defined _WIN32_WINNT
+ #ifdef HAVE_MSMF
+ #define _WIN32_WINNT 0x0600 // Windows Vista
+ #else
+ #define _WIN32_WINNT 0x0500 // Windows 2000
+ #endif
+ #endif
+
#include <windows.h>
And in modules/highgui/src/window_w32.cpp, remove the - marked lines:
#if defined WIN32 || defined _WIN32
-#define COMPILE_MULTIMON_STUBS // Required for multi-monitor support
-#ifndef _MULTIMON_USE_SECURE_CRT
-# define _MULTIMON_USE_SECURE_CRT 0 // some MinGW platforms have no strncpy_s
-#endif
-
-#if defined SM_CMONITORS && !defined MONITOR_DEFAULTTONEAREST
-# define MONITOR_DEFAULTTONULL 0x00000000
-# define MONITOR_DEFAULTTOPRIMARY 0x00000001
-# define MONITOR_DEFAULTTONEAREST 0x00000002
-# define MONITORINFOF_PRIMARY 0x00000001
-#endif
-#ifndef __inout
-# define __inout
-#endif
-
#ifdef __GNUC__
# pragma GCC diagnostic ignored "-Wmissing-declarations"
#endif
#include <commctrl.h>
-#include <winuser.h>
#include <stdlib.h>
#include <string.h>
This will solve the build error.
I had the same problem when building OpenCV 3.0.0 RC1 with mingw32 and the TBB library enabled.
The fix from Rajdhar is already included in the precomp.h file. However, due when building OpenCV with the TBB library, the extra includes trigger the same problem again.
I provisionally solved the issue by moving the definition of _WIN32_WINNT indicated by Rajdhar to an earlier point in the file, before the opencv/core includes:
#ifndef __HIGHGUI_H_
#define __HIGHGUI_H_
#include "opencv2/highgui.hpp"
// MOVED UP
#if defined WIN32 || defined WINCE
#if !defined _WIN32_WINNT
#ifdef HAVE_MSMF
#define _WIN32_WINNT 0x0600 // Windows Vista
#else
#define _WIN32_WINNT 0x0500 // Windows 2000
#endif
#endif
#include <windows.h>
#undef small
#undef min
#undef max
#undef abs
#endif
// END MOVED
#include "opencv2/core/utility.hpp"
#include "opencv2/core/private.hpp"
#include "opencv2/imgcodecs.hpp"
#include "opencv2/imgproc/imgproc_c.h"
#include "opencv2/imgcodecs/imgcodecs_c.h"
#include "opencv2/highgui/highgui_c.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <ctype.h>
#include <assert.h>
// MOVED FROM HERE
#ifdef HAVE_TEGRA_OPTIMIZATION
#include "opencv2/highgui/highgui_tegra.hpp"
#endif
I've had exactly the same problem, and after a quick glance at the file winuser.h, I knew what's going on and added necessary macros to CFLAGS and CXXFLAGS in the command line:
CFLAGS=-D_WIN32_WINNT=0x0500 CXXFLAGS=-D_WIN32_WINNT=0x0500 make
However, the problem was still unsolved. Adding VERBOSE=1 showed that the custom CFLAGS and CXXFLAGS did not take effect at all. It was wierd and I think it should have something to do with my environment, though, i still could not figure it out. Anyway, #Rajdhar 's answer solved my problem, thanks.
I have vim and clang_complete installed but for some reason when I try to auto complete it doesn't see some of OpenGL's functions, such as glBindBuffer, or glEnableVertexAttribArray. I press CTRL + X and CTRL + U to force the auto complete and it shows the function names and parameters, but it's just missing some of the functions.
Even with glfw, I try auto completing GLFW_KEY_ESC but it's not there, I don't know why, it just says User defined completion (^U^N^P) Pattern not found
Does anyone have a solution to this problem? It's very annoying because I use these functions a lot and need the auto complete.
Thanks.
EDIT: Also my include header files are this:
#include <iostream>
#include <string>
#include <GL/glew.h>
#include <GL/glfw.h>
#include <glm/glm.hpp>
I'm on Arch Linux x64 by the way.
All right I found the answer. Because of clang_complete not being able to complete the arguments created by GLEW (because the functions are defined as #define FOO somefunction, and not defined as: #define FOO(arg1, arg2, arg3) someFunction(arg1, arg2, arg3))
To fix this, you have to add this option to your ~/.vimrc file.
let g:clang_complete_macros = 1
Now, you'll get function completion, but still no argument completion. So, you'll have to replace GLEW (sadly) with
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
This will finally complete the arguments, although, if there's an alternative to doing fixing this problem, I'd like to hear.
To expand on zero57's answer.
You could add a clang_complete specific compile flag to define a macro for clang_complete
let g:clang_user_options = ' -DCLANG_COMPLETE_ONLY'
Then in your code you could use
#ifdef CLANG_COMPLETE_ONLY
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
#else
#include <GL/glew.h>
#endif
This isn't a perfect solution but clang_complete should now complete your parameters and when compiling you will be using glew. This worked for me with the YouCompleteMe (YCM) plugin so I assume it works with clang_complete.
As per this answer, I tried printing a uint64_t, but it gives me an error:
error: expected ``)' before 'PRIu64'
Following is the minimal code showing what I am trying to do:
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <cstdio>
class X {
X() {
uint64_t foo = 0;
printf("%07" PRIu64 ": ", foo);
}
};
int main() {}
This minimal code compiles, but my actual code does not. However, I have tried with the 2 lines inside X::X() exactly the same in my actual code, and that does not work.
What should I look for to debug this further? My actual code also #includes other headers. Could that be causing the problem? Does order of including the headers matter?
Edit
PRIu64 is defined as follows on my machine:
# if __WORDSIZE == 64
# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
# else
# define __PRI64_PREFIX "ll"
# define __PRIPTR_PREFIX
# endif
# define PRIu64 __PRI64_PREFIX "u"
In C++ the macros are not automatically defined just by including the file.
You need to add the following:
#define __STDC_FORMAT_MACROS 1
before
#include <inttypes.h>
How to printf uint64_t? Fails with: "spurious trailing ‘%’ in format"
One other possibility for this issue I just found in my own code is if another header already pulls in <inttypes.h> before you define __STDC_FORMAT_MACROS. For example:
Utils.h (Perhaps originally written for C, as it was in our case):
#include <inttypes.h>
// ... Function declarations
MyFile.cpp:
#include "Utils.h"
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
Since inttypes.h has already been included by Util.h, the compiler doesn't include it again, and doesn't see the declaration of __STDC_FORMAT_MACROS.
The solution is either to edit Utils.h to include #define __STDC_FORMAT_MACROS, or to make sure to define it before doing any includes in MyFile.cpp.
#define __STDC_FORMAT_MACROS
#include "Utils.h"
#include <inttypes.h>
The original setup actually compiled just fine on GCC 4.8 on Ubuntu, but failed with an old ltib GCC 4.3 toolchain for PowerPC, which made it all the more perplexing at first.
PRIu64 is not defined where you use it.
Replace it with the string "llu" and your code will compile (but that is not a fix, it just demonstrates the problem)
Maybe the include is missing. Maybe over zealos include guards and it being included without the magic token block the define. Maybe your pch is busted.
If you are on android JNI platform. Put this in your Android.mk:
LOCAL_CPPFLAGS := -D__STDC_FORMAT_MACROS
I use the wxwidget library and I have the following problem:
#if defined(HAVE_TYPE_TRAITS)
#include <type_traits>
#elif defined(HAVE_TR1_TYPE_TRAITS)
#ifdef __VISUALC__
#include <type_traits>
#else
#include <tr1/type_traits>
#endif
#endif
here the #include isn't found. I use the Apple LLVM compiler 4.1. (with the c++11 dialect).
If I switch to the LLVM GCC 4.2 compiler I have no error there, but the main problem is that all the c++11 inclusions won't work.
How can I either use the GCC compiler, but with the c++11 standard or make it that the LLVM can find the ?
any help would be really appreciated.
I'm guessing you have "C++ Standard Library" set to "libc++". If this is the case, you want <type_traits>, not <tr1/type_traits>. libc++ gives you a C++11 library, whereas libstdc++ (which is also the default in Xcode 4.5) gives you a C++03 library with tr1 support.
If you want, you can auto-detect which library you're using with:
#include <ciso646> // detect std::lib
#ifdef _LIBCPP_VERSION
// using libc++
#include <type_traits>
#else
// using libstdc++
#include <tr1/type_traits>
#endif
Or in your case perhaps:
#include <ciso646> // detect std::lib
#ifdef _LIBCPP_VERSION
// using libc++
#define HAVE_TYPE_TRAITS
#else
// using libstdc++
#define HAVE_TR1_TYPE_TRAITS
#endif
This is the command I used to build wxWidgets against libc++ (LLVM C++ Standard Library). Should work on Yosemite and later (at least until Apple breaks everything again):
mkdir build-cocoa-debug
cd build-cocoa-debug
../configure --enable-debug --with-macosx-version-min=10.10
make -j8 #This allows make to use 8 parallel jobs
Slightly modified the code above, to avoid compiler complaints:
Paste the following into strvararg.h just before #ifdefined (HAVE_TYPE_TRAITS)
#include <ciso646> // detect std::lib
#ifdef _LIBCPP_VERSION
// using libc++
#ifndef HAVE_TYPE_TRAITS
#define HAVE_TYPE_TRAITS 1
#endif
#else
// using libstdc++
#ifndef HAVE_TR1_TYPE_TRAITS
#define HAVE_TR1_TYPE_TRAITS 1
#endif
#endif
I'm trying to link GLEW (with SDL and OpenGL - note, not SDL's implementation of OpenGL) in Qt Creator via a QMake file, though I'm not having much luck. No matter what I try, I seem to get the same string errors which deals with conflicting declaration problems stemming from a few typedefs. What I'd like to know is why this is happening, along with what can be done about it.
Example
/usr/include/SDL/SDL_opengl.h:4855: error: conflicting declaration ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, const GLfloat*)’
/usr/include/GL/glew.h:12201: error: ‘PFNGLFRAGMENTLIGHTFVSGIXPROC’ has a previous declaration as ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, GLfloat*)’
Is this because I'm linking with SDL (seeing as how it has OpenGL support), or is there something else going on here?
Qmake File
QT += core
LIBS += -lSDL -lSDL_image -lopengl32 -lGLU -lGLEW
stdafx.h
#pragma once
/*************/
/* #includes */
/*************/
//GL / SDL
#include <GL/glew.h>
#define GLEW_STATIC
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glext.h>
#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
//STD
#include <iostream>
#include <fstream>
//Qt
#include <QListIterator>
#include <QMapIterator>
#include <QVector4D>
#include <QColor>
/********************/
/* Using Statements */
/********************/
using std::cout;
using std::endl;
using std::cin;
using std::fstream;
stdafx.cpp
#define GL_GLEXT_PROTOTYPES
The only solution to your problem is not to use one (either GLEW, or SDL_opengl), or at least do not include both GL/glew.h and SDL/SDL_opengl.h headers in any source or header file.
I have had similar issues before which we "solved" by defining NO_SDL_GLEXT before the inclusion of <SDL/SDL_opengl.h>, so:
#define NO_SDL_GLEXT
#include <SDL/SDL_opengl.h>
I say "solved", because it made the errors go away, but I never investigated possible side-effects or problems (we ended up moving away from SDL shortly after that and never really used it anymore). Perhaps worth a try...