I am having serious problems to compile a code in Windows (regard3d at http://www.regard3d.org). I have read so many post (two days blocked on this problem) here at stackoverflow and other sites, but without success.
The problem is that it needs wxWidgets. For that I am using MinGW. I have VS Community (the latest version). I run my CMakeLists.txt and everytime I get the message
Could NOT find wxWidgets (missing: wxwidgets_LIBRARIES wxwidgets_INCLUDE_DIRS)
I included the wxWidgets installation directory (which is C:\wxWidgets-3.1.0) in PATH variable (I restarted to it takes effect) and created the variable WXWIN (that also contains the installation directory).
The question: What can I do to solve it?
I think the problem is not building the wxWidgets, but make it be found my cmake. As mentioned, I built it using MinGW, thus I have the folder C:\wxWidgets-3.1.0\lib\gcc_dll and the folder C:\wxWidgets-3.1.0\include which contains two more folders named wx and msvc. I am using the following settings before call the cmake:
set wxWidgets_ROOT_DIR=C:\wxWidgets-3.1.0
set R3D_ALT_wxWidgets_INCLUDE_DIRS=include
set R3D_ALT_wxWidgets_LIBRARIES=lib\gcc_dll
set wxWidgets_CONFIG_EXECUTABLE=build\msw
I'm not very familiar with wxWidgets (so this should probably be a comment, but I can't comment because reasons......), but a quick hack that should work is just throwing the path to the library in LD_LIBRARY_PATH or including it by adding
CPPFLAGS += -L C:\wxWidgets-3.1.0\lib\gcc_dll -I C:\wxWidgets-3.1.0\include
to your makefile.
Failing that, you could explicitly set the environmental variables it's complaining about outside of the makefile.
Again, sorry, this should be a comment. It's not... If someone wants to copy it to a comment and delete this, that'd be grand.
Thank all of you. Solved! Yesterday I compiled both with MinGW and VS and settled the wxWidgets-3.1.0_INCLUDE_DIRS and it worked!
Related
My current task is to set up a working environment for an application using (static) Qt and VTK, under Windows 10.
I successfully installed the Qt 5.11.1 static and now want to build VTK. Any version of VTK does, as long as it is compatible to Qt 5.11.1, and the Qt Modules (VTK_Group_Qt) have to be build. For my version, I decided on VTK 8.1.1, but as said, any version would do.
I used the CMake GUI to configure VTK, using MinGW Makefiles (I use a MinGW64), which worked. Then I wanted to proceed generating the Makefile, having turned on VTK_Group_Qt. The paths and version of Qt were already correctly recognized:
Qt5Core_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core
Qt5Gui_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Gui
Qt5Widgets_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Widgets
Qt5_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5
Made sure that all of those exist. After that, I hit Generate and got the following error:
The imported target "Qt5::Core" references the file
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/qt5CoreConfigExtras.cmake"
but not all the files it references
Now, we see that it goes one folder upwards from qtbase and then into the very folder it currently is in, which of course is not a legitimate path. That is, for some reason it tries to go up and then down again, but not with the right amount of folders.
I could try to move the contents of my Qt installation so that the path would be legitimate, but I'd consider that to be pretty much of a smell. Fiddling around in a folder structure that should be correct is not what I understand to be a good solution. I'd rather be willed to change one of the .cmake files of Qt, but that would also be more of a makeshift approach than a real solution as far as I am concerned.
One thing I tried so far was to look at all the CMake variables (checking Advanced in the CMake GUI) in order to see if everything appear to be in order, and especially to see if that faulty path to mkspecs is to be found somewhere there. Found nothing of particular interest.
Does anybody have an idea what went wrong? Tell me if additional information is required. In parallel, I will try to build other versions of VTK, but I'm not too confident that this will solve the issue.
I found a solution which I want to present here, but I consider it a makeshift approach rather than an actual solution, and I hope to see a better answer.
I went to qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/ and changed the file Qt5CoreConfigExtrasMkspecDir.cmake (after making a copy).
The original file contains a single line
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++")
which leads to the faulty path. I changed it to
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/mkspecs/win32-g++")
And it now works fine. Still, I don't feel good about having to change a file of Qt, since I consider the answer the question "Is this famous library at fault?" to be "Most likely I used it wrong."
A possible explanation would be that I used the wrong install prefix when configuring Qt, but shouldn't I be allowed to put any valid writeable path in there? Plus, the prefix is still in the cmake file and thus has some validity.
While this is an answer since it fixed the problem, I'd really like to read comments about what could have originally went wrong.
I have been struggling with this problem for quite a while, and unfortunately neither my own reasoning, nor google search helped me. In simple terms, I am trying to use nativeErrorCode() function with QSqlError class. Compiler says: mainwindow.cpp:43:86: error: ‘class QSqlError’ has no member named ‘nativeErrorCode’. This is the line that it references (to be exact, two lines):
errorCreatingBooksTableMessageBox.setDetailedText((query.lastError().nativeErrorCode().isEmpty()) ?
query.lastError().text() : query.lastError().nativeErrorCode() + "\n" + query.lastError().text());
Problem seems trivial, but I can't find an answer on my own. #include is in mainwindow.h file. After some research, I noticed other people on other forums suggesting that compiler uses wrong version of the header file, which would seem very likely to happen since function nativeErrorCode() was introduced in Qt5. I tried to move qt4 folder to trash, but still, no effect. Any help would be appriciated
I am not sure which OS you encounter this issue. However In most of the Linux OS Image, prebuild with Qt4, Even we build Qt5 libraries additionally, the system environment may use old Qt4 libraries to generate make files. This is very common if we are building Qt5 from source codes. So it would be better you can try to execute qmake from Qt5 path. So the Makefile will be created to build for Qt5 libraries.
In order to confirm, Open the Makefile and check the variable QMAKE is refering to Qt5 or Qt4 libraries.
I am updating this from my system for your reference, "QMAKE = /home/user1/Qt5.6.0/5.6/gcc_64/bin/qmake" From this, It is clear that Makefile is using Qt5 libraries and further compilation, Qt5 libraries will be used to compile my application source code.
I recently begin to use Qt and decided to use it with Visual Studio (2013).
The problem is that when i create the project the Qt classes even the most common can't be included (as QApplication) even if i had to it every Modules (core GUI...). Intellisense underline it in red saying :"cannot open source file QApplication". And when i try to run the project, it tells me that i missed some .dll. The weirdest thing is that i already manage (2 times) to make it worked, simply by creating the project without doing anything special(i think).
Moreover when i use the qtcreator it works fine but i'd like to use VS.
Sorry, i had a hard time being specific since i really don't have a clue.
In addition #drescherjm comment, you should also check that you have an system environment variable set - The variable name should be QTDIR and the path should be the path of your installation - on my system this is C:\Qt\Qt5.5.1\5.5\msvc2013.
OK, it seems i found a way to resolve the problem but i still don't get why.
It appears that if i go in the Qt options even if the path is already set, i need to select it and press ok. And then build the project and reopen it for intelisense to work. And it worked. But it's weird because i already fund the place where the qtdir variable is stored and it was alright but the project still didn't worked??
I am running in situation where I have two different versions of Qt installed, the compiled with mingw one, and the other with visual studio.
Now, When I compile my program with Qt MinGW version and run it, I got a message have scrambled text, saying that one of essential Qt modules not loaded.
My question is, how I can set the path to Qt essential modules for my application with C++. I looked at documentation and found addLibraryPath method but it seems like for Qt plugins only.
Edit
It seems I misunderstood the question, as SIFE comment that he needs to load Qt modules (like QtGui4.dll), not plugins. The answer for plugins is left here, in case it might help someone.
Plugins
Qt loads plugins that are in the SDK/plugins by default. The problem is, it finds the wrong SDK first...
If I remember right, Qt first search in the directory .. So you can copy the 'plugins' directory near your *.exe : plugins for msvc copied near the msvc-compiled exe, and plugins for gcc near gcc-compiled exe.
If you do not want to copy the plugins directory, you can use setLibraryPaths (not tested, but might work)
Last but not least, you can also use the qt.conf approach.
Modules
Modules are not dynamically loaded, in the sense that they're part of the dependencies of the application, so they are loaded at exe startup, and not via LoadLibrary. So, the solution is simple: just copy the dlls in the same folder than the one containing the *.exe
Concerning compiler, the proper library/include settings should be done by QMake.
QMake creates your makefile/VS-Project using the libraries found in the same Version Qmake belongs to.
Try calling QMake using the complete path explicitely for each Qt-Version
e.g.
c:/myQtMinGwProject>c:/Qt4_mingw/bin/qmake
c:/myQtVSProject>c:/Qt4_VS2008/bin/qmake -t vcapp
Concerning run-time, make sure the dlls for corresponding version are in PATH
I hope it helps
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.