I'm using VisualStudio 2022 community to develop linux program. The cross-platform compile do works and compile outputs shows Output view well.
But when double click the error message, it can't jump to source code of error place.
How to fix it?
I use GCC 8.4 on Centos 8 OS.
Thanks
I know the reason of my problem now.
Setting of "Remote build root" is incorrect in CMakeSettings.json.
This is the root dir of building on server, this path combine with the file path from gcc error message should point to the correct source file
On a Windows system, currently I'm trying a waf configure on a directory of code, and it spits out the error "could not configure a C compiler."
Now, I'm 100% certain that I have gcc and g++ installed and in my path because when I type gcc --version, it gives me the current version information. (I'm using mingw and the gcc/g++ are in the /bin subdirectory).
In the author's code directory there is a wscript file which looks like
C_COMPILER = 'gcc-4.7'
CPLUSPLUS_COMPILER = 'g++-4.7'
Now, I have tried changing the strings to simply gcc as well as gcc-4.8.1 (since my current version is 4.8.1), but it still says could not configure compiler.
I tried reading one solution on this same site that looks related, but the solution was on ubuntu and trying to work through those commands didn't help
could not configure a c compiler
I'm at the end of my common sense here after making sure I have gcc and g++ installed, trying different strings in the wscript file trying to get it to recognize I have them installed, and could use some help, thanks.
Edit: I've now tried simply deleting the lines in the wscript file where it changes the compiler name, and suddenly waf configure goes through, but the waf build fails saying things like it can't find really basic things like include vector. The output says it's defaulting to msvs (microsoft visual studio) whereas the author says gcc/g++ is needed; maybe this is the issue but how do I get waf configure/build to use g++/gcc as default?
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I'm trying to get input from an xbox controller, I went to this page:
http://www.codeproject.com/Articles/26949/Xbox-360-Controller-Input-in-C-with-XInput
and I'm just test running his source, good thing I did because it found an error:
C:\Users\me;)\Desktop\XBOX360Test\XBOX360Test\CXBOXController.h|9|fatal error: Xinput.h: No such file or directory|
Can I don't know what the issue is, doesn't Xinput ship with windows?
I'm late I know, but I get the same error.
Opening the project in Visual Studio works fine, but compiling with gcc doesn't. Seems like the compiler of VS knows more than gcc and you need to compile it with that one. Here's how:
http://msdn.microsoft.com/en-us/library/ms235639(v=vs.80).aspx
I'm trying to compile the "GTK# Hello World" example at http://mono-project.com/Mono_Basics in Windows 7 (64bits). I'm getting this error:
error CS8027: Couldn't run pkg-config: ApplicationName='pkg-config', CommandLine
='--libs gtk-sharp-2.0', CurrentDirectory=''
I have successfully compiled and run the "Console Hello World" example.
I have installed Mono-2.10.8.
Thanks in advance for your help
I tried to compile a GTK# example in a Windows 7 with Mono 2.10.8 and the options you used with the compiler, so i have the same error then i tried to reference each assembly by hand so it works fine.
Here is the full command, i tested in a Mono 2-10.8 comman prompt.
gmcs ButtonApp.cs -r:C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/pango-sharp.dll,C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/atk-sharp.dll,C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/gdk-sharp.dll,C:/PROGRA~2/MONO-2~1.8/lib/mono/gtk-sharp-2.0/gtk-sharp.dll
I hope this can helps
You were trying to use pkg-config which you do not have. pkg-config with --libs turns specified packages (like gtk-sharp-2.0 in your case) into references to libraries. If you don't want to install pkg-config, you have two options:
manually reference needed libraries with compiler options;
create a project with these libraries referenced.
I recommend the second option, as compiling by specifying all sources and references directly could be good for hello-world examples, but not for the something bigger. You would make your own script to compile the project, so why not use something designed just for that - like xbuild or make. MonoDevelop should contain empty Gtk# project template.