Jgrasp C++ compile issues - c++

When I try to compile a simple source code in c++ using jgrasp i get this
----jGRASP wedge2 error: command "g++" not found. ---- This
command must be in the current working directory ---- or on the
current PATH to use this function. ---- PATH is ";C:\Program Files
(x86)\NVIDIA
Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Microsoft\Web Platform Installer\;C:\Program Files
(x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files
(x86)\Windows Kits\8.0\Windows Performance Toolkit\;C:\Program
Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files
(x86)\QuickTime\QTSystem\". ----jGRASP: operation complete.
anyone know how to fix it?
Im using windows 8

You either don't have a C++ compiler installed on your machine or you have a C++ compiler installed and have not added it to your PATH.

Related

Cannot open include file: 'stddef.h': No such file or directory in cstddef QtCreator

When I want to compile my Qt project, debuger shows me that stddef.h was not included into ...\VC\Tools\MSVC\14.27.29110\include. I tried to solve this problem using adding to system Environmental Variables path to Win SDK Kits (folder include). But this doesnt solve my problem. Also I instaled Windows Universal CRT SDK but this giving me nothing. Also I tried to reinstall VS and Qt,check Qt for update, add to environment variable PATH path to folder bin from MSVC folders and change include in cstddef from stddef.h to stddef. This is the list of my environment variable PATH:
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\
C:\Program Files\dotnet\
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0
And this is user environment setting PATH:
C:\Users\karat\AppData\Local\Programs\Python\Python37-32\Scripts\
C:\Users\karat\AppData\Local\Programs\Python\Python37-32\
C:\Users\karat\AppData\Local\Microsoft\WindowsApps
C:\Program Files\JetBrains\PyCharm Community Edition 2019.2.1\bin
C:\Users\karat.dotnet\tools
%USERPROFILE%\AppData\Local\Microsoft\WindowsApps
%USERPROFILE%.dotnet\tools
Could you recommend me a way to solve this problem and tell me why this could happen at all?

MSBuild 2019 ignores INCLUDE environment variable

I am working with two machines that have Visual Studio 2019. One has Community edition, the other has Pro edition.
The pro edition of MSBuild is completely ignoring the INCLUDE environment variable, so the project I'm trying to build (ICU) cannot find stddef.h. The stddef.h file is in the Windows Kits 10 ucrt directory, which is included in the INCLUDE env var.
The community edition doesn't do this.
When I build the project with the /v:diag option I can see most of what's defined in the INCLUDE env var is added to a variable named CAExcludePath.
Here's the INCLUDE env var: INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\include;;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\atlmfc\include;;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\VS\include;;C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt;;;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\VS\UnitTest\include;C:\Program Files (x86)\Windows Kits\8.1\Include\um;C:\Program Files (x86)\Windows Kits\8.1\Include\shared;C:\Program Files (x86)\Windows Kits\8.1\Include\winrt;;
And here's the CAExcludePath: CAExcludePath=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\include;C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt;;C:\Program Files (x86)\Windows Kits\8.1\Include\um;C:\Program Files (x86)\Windows Kits\8.1\Include\shared;C:\Program Files (x86)\Windows Kits\8.1\Include\winrt;;
Why does this happen and how do I prevent it?
MSBuild 2019 ignores INCLUDE environment variable
I think you should not set these paths into Environment Variables. For C++ projects, VS does not recognize the library path in system environment variables by default and this is not the VS job.
Usually, you should set extra library paths in VS IDE. Right-click on your project-->Properties-->Configuration Properties-->VC++ Directories-->Include Directories or Properties-->Configuration Properties-->C/C++-->Additional Include Directories. You can refer to this official document.
However, when l install Windows Kits tool, this path is included in the include path by default and you can use this in your code directly. See this:
So l am afraid you have something wrong when you install the Windows Kits tool. Please follow this document to install the right tool and before you finish it, please install the related extension which is the last step in the installer in Visual Studio 2019 to integrate the tool.
I think when you install the extension, these paths will be included into VS automatically and you can use them directly.
Besides, if you do not want to install this extension, you can add the include path manually by the steps I mentioned above.
If you have done these steps and still faced the same error, I think you should check your Environment and follow these suggestions:
1) close VS Instance, delete .vs, bin, obj folders,reopen your project and then build again
2) do a repair in VS Installer
3) if your VS is not the latest, please update your VS and do not forget to update Operation System at the same time.
Hope these help.
Use the IncludePath environment variable instead.
set IncludePath=%INCLUDE%
IncludePath is not ignored/overwritten when running msbuild, and I was able to successfully compile my project/solution by setting it.
On my machine, setting IncludePath overrides 3 paths which would otherwise be set. The 3 paths have analogs (same header files but for different versions) in my %INCLUDE% paths, so it seems safe (and in fact prudent) to ignore/clobber/leave these out.

jvm.dll is missing from your computer

I have Visual Studio C++ Project, which has to call some java functionality. I'm going to use JNI. I have specified additional include directories:
C:\Program Files (x86)\Java\jdk1.7.0_10\include
C:\Program Files (x86)\Java\jdk1.7.0_10\include\win32
and additional library directory
C:\Program Files (x86)\Java\jdk1.7.0_10\lib
and was able to compile needed code. But I still cannot run it because of the next error:
The program can't start because jvm.dll is missing...
Anyone help please that what i should do now...?? Is there any way to specify the path for JVM.DLL ???

Compiling Microsoft CRT 11 (msvcrt110.dll) - What is the correct order of includes?

I am trying to compile the Microsoft CRT 11 by myself (The version that comes along with VS2012).
I'm aware that until VS2008 this action was completely supported by Microsoft:
http://msdn.microsoft.com/en-us/library/k9a8ehy3(v=vs.90).aspx
But since VS2010 you are not supposed to do it anymore, and I'm aware of the risks (mainly - compiling it wrong, and having problems that you can't figure or solve)
I'm using the following directories that come with VS as input code and header files:
Code:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src
Headers:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
C:\Program Files (x86)\Windows Kits\8.0\Include\shared
C:\Program Files (x86)\Windows Kits\8.0\Include\um
C:\Program Files (x86)\Windows Kits\8.0\Include\WinRT
(So far the only changes I have made are to remove some MSIL sources from the project)
Most of the code compiles already. But I can't compile the file
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\assert.c
Because of the error:
error C3861: '_ReturnAddress': identifier not found
If I add
#include <intrin.h>
it is solved. But I think it's supposed to be solvable without direct changes to the code.
Of course I'm constantly facing new challenges. But I think the solution to the current one is to fix the include order of the header directories. In which order should the header directories be used?
You can force an include (without changing the source code) in the visual studio project (although I'm not sure if it's a better solution).
To do so, right click on the .c in the solution explorer then go in C/C++ -> Advanced -> Force Include File and add intrin.h (or add /FI"intrin.h" in the command line).

Cannot build a C++ project with Eclipse CDT

I have a C++ project which uses CMake, and I want to try using Eclipse CDT with mingw (this project already compiles and run with MSVC, code::blocks, etc.)
With Eclipse CDT, I choose a target, and right click to build the target, but I get the following message :
22:59:13 ** Build of project OgreProcedural-RelWithDebInfo#ogreprocedural_eclipse **
"e:\MinGW\bin\mingw32-make.exe" -C E:/Prog/Builds/ogreprocedural_eclipse OgreProcedural
Cannot run program "e:\MinGW\bin\mingw32-make.exe": Invalid directory.
Error: Program "e:\MinGW\bin\mingw32-make.exe" not found in PATH
PATH=[E:\Prog\ImageMagick;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\Graphviz2.26.3\bin;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files\TortoiseHg\;C:\Program Files\doxygen\bin;e:\prog\libs\qt\bin;C:\Program Files\7-Zip;e:\mingw\bin;C:\Program Files (x86)\CMake 2.8\bin;e:\python;%GROOVY_HOME%\bin]
... but the mingw\bin directory is in the path, and mingw32-make is inside it.
Am I missing something?
EDIT:
Finally, I was able to build projects, but among the multitude of build targets generated by CMake, some build fine and some others don't.