I am trying to debug a Fortran Console application from Eclipse under Windows 10.
Building and running work fine, using the compiler from MSYS2.
However, starting the debugger yields:
Error in final launch sequence:
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Error creating process /c/Windows/system32/E:/till/uni/wasa/wasa_git/WASA-SED/E:/till/uni/wasa/wasa_git/WASA-SED/wasa_dbg.exe, (error 2).
The gdb.exe is found correctly, but it seems as if the path to the binary is prepended with /c/Windows/system32/ and one time too many the actual path E:/till/uni/wasa/wasa_git/WASA-SED, which obviously causes gdb to fail.
I tried using absolute, relative, and no paths to the binary in the debug configuration settings, all with the same result.
How can I fix this? Thanks in advance.
For me, the problem seems to be related to the version of gdb that I use.
I had used an instance from a recent MSYS2 distribution (i.e. GNU gdb (GDB) 11.1), which produced the error above.
Falling back on an older version (GNU gdb (GDB) 7.9.1) worked as expected.
I solved this by prepending the PATH-variable with the path to the old MSYS2 directory:
SET PATH=c:\mingw4eclipse\bin\;c:\mingw4eclipse\mingw_64\bin\;%PATH%
Putting this into batch file that then calls Eclipse ensures that no other workflows (using the newer MSYS2) are affected.
Related
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
I installed haskell-idea-plugin to make a Haskell IDE.
The plugin can do the following things as claimed on https://github.com/Atsky/haskell-idea-plugin.
Haskell syntax highlight
Cabal syntax highlight
Error checking with ghc-modi.
Simple completion based on ghc-modi
Show type of symbol (Ctrl + Shift + T, or ⌘ + Shift + T on mac)
Build of cabal projects
Installation of cabal packages
REPL
But when I tried to debug the following simple Haskell file
module Main where
main = do
str <- getLine
putStrLn $ str++str
it reported: Debug execution error: Internal error occured while executing debug process for untitled
And here is my Haskell-debugger configuration:
I also tried other options but it didn't work.
And here is my environment:
Ubuntu14.10
oracle-jdk6.0
IntelliJ IDEA 13.1.16
haskell-idea-plugin
ghc-mod
remote-debugger
Although I am under windows, I got the similar error. The steps that worked for me to resolve the error:
Try run ghc-modi.exe from the command line. It were times when it resulted in error
ghc-modi.exe: C:\Users\Nick\AppData\Roaming\cabal\bin\ghc-mod: createProcess: does not exist (No such file or directory)
This is fixed by recompiling and installing ghc-mod from the sources, I guess ghc-modi contains the hard path to ghc-mod, and the compiled files are not movable across different machines.
It seems that the remote-debugger has the same hard dependency on the position in the filesystem. During one of my previous installations I copied it from different machine and got C:\Portable\ghc-7.10.1\lib\settings: openFile: does not exist (No such file or directory).
The fix is, again, rebuild remote-debugger from the sources on the current machine.
Of course all these executables should be accessible in PATH.
After that I created hello project from scratch and the (remote) debugging worked just fine.
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 was able to cabal install text-icu without errors. (I used --extra-lib-dirs and --extra-include-dirs to point to the lib and include directories in the binary distribution of icu4c.)
I was also able to build the following simple program that uses text-icu, by doing ghc --make icu.hs:
-- icu.hs
import Data.Text.ICU
main = print $ Locale "tr-TR"
No errors or warnings in either of these steps. But when I try to run the compiled program, icu.exe, I get no output at all. I expected to get a line with Locale "tr-TR", but instead I get nothing -- not even an error or warning. This remains the case if I try
main = do
print $ Locale "tr-TR"
print "Done"
so using the text-icu stuff seems to cause the program to silently fail. echo $? yields False.
Does anyone have text-icu up and running on Windows? Can you tell me what I'm doing wrong?
Stack includes a copy of msys2 on Windows, which contains the pacman package manager, so we can run:
stack exec -- pacman -Sy mingw64/mingw-w64-x86_64-icu
stack build text-icu
I managed it by doing:
Download the binaries from http://site.icu-project.org/download/56#TOC-ICU4C-Download, specifically http://download.icu-project.org/files/icu4c/56.1/icu4c-56_1-Win32-msvc10.zip.
Extract the contents of icu/bin into the directory C:\bin which is on my %PATH%. Extract the contents of icu into the directory C:\bin\icu.
Use Stack to run stack ghci text-icu --extra-lib-dirs=c:\bin --extra-include-dirs=c:\bin\icu\include.
In GHCi, run import Data.Text.ICU.Normalize, then :set -XOverloadedStrings, then normalize None "test".
For each dll that is reported as cannot be found, e.g. icuuc.dll, take the C:\bin\icuuc56.dll and make a copy at C:\bin\icuuc.dll. For me, there were three relevant dlls.
After all that, I can normalise a string in ghci.
This is how windows reacts to a missing static dependency. When the operating system starts a process it looks for static dependencies. If one is missing, then program is not started.
Use depends.exe to find out what import is missing. That could be a missing dll or one that is the wrong version.
Depends is available with
1. Visual Studio
2. The Microsoft Platform SDK
3. Other microsoft packages
4. http://www.dependencywalker.com
It pretty indispensable when tracking down what is happening in this case.
you should check if there are some DLL missing with cygcheck.check the path and the windows enviroment variables too with it is right. Or try to reinstall following the haskell procedure.
http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation
good luck
I'm working on a project in Xamarin.iOS, and it happens to go through a build server (running on a Mac).
The build seems to commonly fail, but even with the --verbose or -v it seems to Silently fail. For example, right now, it seems to fail after optimizing the graphics for iOS. The last line of the build says Build complete -- 0 errors, 0 warnings. But then I get a Build step 'Execute shell' marked build as failure from Jenkins. I know that this is a failure in the mdtool build, because I have had a successful build before, and I know there are several more steps before it actually succeeds.
The next step in the successful process should be Compiling to native code, but for some reason it fails before getting to that, or at least outputting it to the console.
Thanks in advance for the help!
There's a few places in the mdtool build logic that didn't properly catch exceptions when executing shell programs which I (hopefully) fixed for Xamarin Studio 4.0.2.
Without seeing the full build log it's hard to say for sure, but it might be that whatever shell command that it is trying to execute either doesn't exist or isn't marked with execute permissions.
The programs that I can think of off the top of my head that mdtool will invoke for the iOS builds are:
pngcrush (optimizes .png files)
plutil (optimizes .plist and .strings files)
codesign (although this one gets called after compiling to native code)
and of course, mtouch which is what is used to compile IL to native code. The mtouch command is part of Xamarin.iOS while the other 3 utilities are part of Mac OS X (or Xcode).
The solution for the other person with a similar problem that I helped debug a week or 2 ago was because he had modified his PATH environment that launchd launched apps with to not include /usr/bin and so mdtool couldn't find the utility programs listed above.
I'm not very familiar with Jenkins (I know we use it at Xamarin, but I'm not part of the team that does), so make sure that the PATH environment that it launches mdtool under is setup to include /usr/bin.
Hope that helps.