I can be a real dummy when it comes to following instructions sometimes, pardon me. I'm in a bit of a hurry to get YAML files working with my program. I have downloaded the YAML files from the official site, I have downloaded an installed the latest CMake. What do i do now? I don't understand DLL creation nor the issues that there seem to be.
When I open CMake I put in the path to the extracted yaml-cpp-0.2.7 folder with the yaml-cpp.pc.cmake file and I set up the build path. Is there anything else I should do here? I get this error:
CMake Error: CMake was unable to find a build program corresponding to ""Visual Studio 9 2008"". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: Could not find cmake module file:C:/path/yaml-cpp-0.2.7/build/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Could not find cmake module file:C:/path/yaml-cpp-0.2.7/build/CMakeFiles/CMakeCXXCompiler.cmake
Also once i'm done with this what should I do next to be able to launch the example code from the site? Which configuration should I use to be able to launch the file on VS Express 2010? I'm stuck, I can't find answers anywhere.
I have made a mistake here, i tried to get the CMake file going on a computer which didn't have the IDE installed, i installed VC++ 2010 and it works now.
I loaded the yaml-cpp solution into VC++ 2010, bulit it, linked everything and it works fine now.
Related
I'm trying to run a piece of software I built in MSYS2 MINGW32 shell. The software is 32bits (don't have time to port it to 64bits) and there is one statically linked executable. Here is how I setup the build environment:
Installed a fresh copy of MSYS2;
$ pacman -Syu
Installed the following packages: git mingw-w64-i686-gcc mingw-w64-i686-cmake mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-zlib mingw-w64-i686-libpng mingw-w64-i686-make
Git checkout the repo
Run the build in CMake
Build runs fine and the exe is generated.
Now the problem starts: the executable can't run and displays an error message about missing DLLs. I copied the missing DLLs to the same folder of the executable, and them another error message pops up complaining about error 0xC000007B, which I tracked down to be missing dependencies. After a while I figured out that the problem was that some of the DLLs is missing a dependency itself. Copied this last dependency to the folder.
Now, the big question: I can run the exe perfectly fine in the MINGW32 shell but I can't run it neither in cmd.exe nor by double-clicking in Windows Explorer and this is a problem (I can't ship a software this way). Is there any way to produce a binary that is able to run from explorer and from cmd.exe? What is the cause of this problem? Can it be mitigated?
I solved my problem!
After a lot of research, I realized that nothing was wrong with my MSYS2 build/setup/dependencies. The real problem was that CMake hide one parameter for the linker: -mwindows. Actually, the CMake find_package routine from one of the libraries I'm using (SDL) added this parameter to the linker command line parameters.
Adding a -mconsole to the linker parameters (using add_link_options("-mconsole")) solved the problem. The CLI now works as expected.
Thank you all for your help.
I am trying to run SFML-LiquidFun-Water-master open source file (https://github.com/alextrevisan/SFML-LiquidFun-Water) on VS2015, but it had some errors (such as there is no proper library "Box2D", "Liquidfun"), I realized that I have to install liquidfun librabry and bring it to the source code which I want to run. I downloaded liquidfun library from https://github.com/google/liquidfun and Cmake from https://cmake.org/ and followed instructions based on here http://google.github.io/liquidfun/Building/html/md__building_windows.html but It keep saying that there is no such command name Cmake whatever.. What am I supposed to do to run source code thank you!!
I have CMake working perfectly fine with Visual Studio 2015. I wanted to try VS Code with C++ and CMake extensions, but when I try to call the build command (configured to F7 by default with the CMake extension for VSCode), I only get the message:
command 'cmake.build' not found
Is it trying to tell me it can't find CMake ? Because Cmake is installed and working so... I also tried changing in the settings to the full path to cmake with no success. I installed both CMake and CMake Tools from Extensions. Also the toolbar for CMake doesn't appear on the blue VSCode toolbar as shown in CMake Tools extension doc.
Edit:
The author of that extension believes they've resolved this issue in the latest version 0.9.7.
https://github.com/vector-of-bool/vscode-cmake-tools/issues/157#issuecomment-307005140
So, I've just pushed 0.9.7:
No more dependency on twxs.cmake, so that shouldn't be causing any
issues anymore
#ytimenkov fixed some version parsing code that was
lying about what version of CMake was installed. Should fix issues
people are seeing with pre-3.7 versions.
#ytimenkov added better
errors when initialization failed. This should help create future
tickets!
As such, I'm going to close this issue and ask that anyone
with any further issues open a new ticket using the new error messages
that appear during a failed initialization.
I too had this issue and was given a solution here in my ticket.
For some people, one of their dependencies isn't getting installed correctly on our system. So you need to install another additional extension to get it to work.
It's called "CMake" or "twxs.cmake" (actual package name) and can be found here: https://marketplace.visualstudio.com/items?itemName=twxs.cmake
If it still isn't working, some have reported that they needed to uninstall both extensions then reinstall them both to get it to work--making sure to restart VSCode.
try this:
create a new copy of "mingw32-make.exe".
rename the copy to "make.exe".
restart your vscode.
I've downloaded the source files for the TBB libraries, with the intent to build them and link them into my CMake project. The readme file says "type 'gmake' in this directory to build and test."
My question is - how do I run gmake on a Windows machine.
The solution in this answer didn't work for me. This is what I get:
From the log I see that make unable to find Microsoft compiler cl.exe. To fix this, you must use one of the "Visual Studio command prompt"-s, those are cmd with environments targeted to command-line tools.
If you use MigGW by chance, the command should be
make compiler=gcc.
In this case, path environment variable should contain path to MigGW.
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.