I'm working on a project using PCL (point cloud library) for which I need to configure some code files using CMake. But some of these files aren't getting configured and the error CMake shows for those files is "Qt4 not found". I already have Qt 4.8 installed and this is the only Qt version I have. Also, for some of the other files, CMake used Qt without showing any error. And when I run qmake.exe, it shows "Qt : Untested windows version 6.2 detected". And for all the Qt5 related entries, CMake shows "NOT FOUND". Have I installed the correct version of Qt? And how can I get CMake to detect Qt4?
I'm using windows 8.1 64bit
When I typed qmake -v in command prompt, I got this -
Qt: Untested Windows version 6.2 detected!
QMake version 2.01a
Using Qt version 4.8.0 in C:\Qt\4.8.0\lib
cmake to find Qt users qmake, so if you run it not from command line,
make sure that global environment variable PATH set to proper value, so cmake can find qmake
cmake cache libraries search results, bad results also. Because of that, if it can find some library, you install it, then rerun cmake it can show again "library not found" message, even if your setup is corrret. So make sure to remove CMakeCache.txt before rerun cmake.
Related
This is the first time I've come across CMake. When I follow CMake instructions to extract a C# project, it give the below error.
Selecting Windows SDK version to target Windows 10.0.15063.
The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error in CMakeLists.txt:
No CMAKE_C_COMPILER could be found.
CMake Error in CMakeLists.txt:
No CMAKE_CXX_COMPILER could be found.
I tried to fix the error by googling, but not able to find the problem yet. Can someone please help me.
Note:
I am running CMake on a Windows 10 computer, that has Windows 8.1 SDK, Visual studio 2015, 2017 installed.
I was having the same issue with a very similar system configuration. In my case, it appears to have been related to this question which pointed me to this bug report.
So the fix (for me) was to update CMake:
Uninstall your current version of CMake.
If you installed it using an installer script, you'll need to run the uninstaller as noted on CMake.org.
Installer tool has changed. Uninstall CMake 3.4 or lower first!
If you installed a zipped portable version, you can simply delete it and/or move it out of your PATH environment variable.
Download the latest CMake (at time of writing, 3.14.5). This time I opted to install the zipped version and manually add it to my PATH environment variable since I only ever use CMake from command prompt anyway, but you're welcome to use the MSI instead.
And after that everything worked fine! Hope this helps.
I'm using external cmake with msys2, since cmake-gui provided by msys2 won't run (invalid win32 application). Now the problem is there's only so much I can configure using cmake-gui. I downloaded OpenALSoft today and when I ran make install it installed to C:\Program Files (x86)\. How do I configure external cmake to install into mingw32 or mingw64 depending on what's running? On top of that, I'm having a problem differentiating between PATH RPATH and PREFIX (and how those correspond to msys2 install structure), so if you could, please, clarify those too, I'd really appreciate that.
I always use this invocation to make sure the install directory is set to /mingw32 or /mingw64:
MSYS2_ARG_CONV_EXCL=- cmake . -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
And then when you want to install the built project, you must do this:
make install DESTDIR=/
All of this trickiness is due to the fact that CMake is a native Windows program that does not understand MSYS2-style paths like /, and MSYS2 has some automatic conversions of paths that happen when it detects you are running a native Windows program like CMake.
By the way, MSYS2's cmake-gui works for me, so maybe you should try reinstalling the CMake package in MSYS2 or something. However, I expect my answer to work for both the external CMake and the one in MSYS2.
I'm trying to compile a piece of MATLAB code containing a makefile. For the reason that I'm using Windows, I need to use Cygwin.
I have downloaded and installed Cygwin. When I tried to compile the code using make, there was an error that g++ is not found.
I searched for Cygwin package manager on the net and I installed apt-cyg but when I search for g++ using apt-cyg search g++, there is no result there!
I have updated package list (apt-cyg update) but finally I could not find c++ compiler for Cygwin!
How can I do it by apt-cyg package manager or any other way?
Try installing the package cygport. It will take care of many of the dependencies you need, including g++.
Finally I could find the answer in this link.
If one uses the MinGW installation file again, one can add some other packages.
I installed all Devel packages for MinGW and followed this tutorial which helped me to solve the problem.
If using apt-cyg and looking for g++ I would suggest to look up for the name gcc-g++ instead of just g++.
In this case the command would look like:
apt-cyg search gcc-g++ - for searching the package
or
apt-cyg install gcc-g++ - for installing the package
Hint:
Names of packages can be checked on the "Select Packages" page of the Cygwin installation program. There is no need to install, sometimes it is easier just to check the name of a package and cancel the installation.
Trying to build PCL 1.8 using VTK 7.0.0. Target is Visual Studio 2015.
Using the VTK OpenGL2 backend I got errors similar to those reported here and here which indicate OpenGL2 is not supported for PCL yet.
However, using the original VTK OpenGL backend I get different errors:
The list of VTK libraries PCL projects link against includes libraries whose names suggest both OpenGL and OpenGL2, even though VTK is only configured with one or the other backend. For example, "vtkDomainsChemistryOpenGL2.lib" (when VTK backend is OpenGL).
"vtkDomainsChemistryOpenGL2.lib" does not exist, causing a linker error. However, a library called "vtkDomainsChemistryOpenGL2-7.0.lib" exists, so it appears a version suffix is added when VTK is built, but is not added when CMake generates the list of libraries to link PCL projects with.
vtkVertexBufferObject.cxx(104): error C2039: 'GetExtensionManager': is not a member of 'vtkOpenGLRenderWindow'. Class vtkOpenGLRenderWindow is suspiciously tagged with VTKRENDERINGOPENGL2_EXPORT (again in an OpenGL build).
I don't know whether the problem lies in VTK or PCL. The CMake build system is completely opaque to me so I am getting nowhere with this.
Just following up to myself (again)...
The problem was that, because I had initially built the "INSTALL" project of VTK using the OpenGL2 backend, then changed the backend to OpenGL and built the "INSTALL" project of VTK again, both backends existed in the install folder. VTKConfig.cmake (which PCL uses to link with VTK) finds and links against all modules that it finds in the install folder, thus attempting to link against both incompatible backends.
The VTK build system does not detect that conflicting modules are already present when installing, and the "make clean" or "rebuild" options don't remove conflicting modules (VTK does not have an uninstaller). Deleting CMake caches, or creating a new clean build directory, is not sufficient to clear up this mess.
So the only solution was to manually find and delete the VTK install folder ("C:\Program Files (x86)\VTK", for the record) if you need to change the VTK backend.
I am having trouble compiling wxwidgets with mingw on Windows 7 x64. It compiles for 30+ min, then runs out of memory. My computer has 6 GB of memory, so I don't know what is wrong.
Someone mentioned something about a 64 bit version of MinGW. Would this help, and if so, how would I use this?
I am able to compile just fine with Visual Studio.
Also, if I wish to use it with CodeBlocks, how do I add wxWidgets to CodeBlocks (I.e. link to it)?
Actually, I somehow solved my own problem a few days ago, but forgot to note this up here.
I deleted the wxWidgets folder, reinstalled it, then compiled it according to the directions in a zip file here: http://dev.arqendra.net/#cbnb.
After you have installed wxWidgets, fire up msys, cd to the wxwidgets folder, then run
mingw32-make -f makefile.gcc BUILD=debug UNICODE=1
(Assuming mingw32-make is in your path).
Wait a while (maybe 20 minutes, depending on your computer's processing power).
Repeat this for release i.e.:
mingw32-make -f makefile.gcc BUILD=release UNICODE=1
Next, you have to deal with a quirk by copying \wxWidgets\include\wx\msw\setup.h to \wxWidgets\include\wx.
You can apply other options to your liking.
Also, to "add" wxWidgets to a project in C::B, you can just set up a wxWidgets project, saving you the trouble of adding the right directories (and .a libraries).
I used MinGW 4.5, installed using the "MinGW GCC 4.5.0 Installer" from their site. To compile wxWidgets using MinGW, I used:
cd %WXDIR%\build\msw
mingw32-make -f makefile.gcc BUILD=debug RUNTIME_LIBS=static
In codeblocks there is a dialog for setting the path for MinGW. You set the path for wxWidgets in the new app wizard. I really recommend you set the same MinGW version you used to compile wxWidgets.
This is probably due to this gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601#c9 you may try installing another version of gcc.