Program can't start because *.dll is missing - MinGW, Eclipse, Windows 7 - c++

I am well aware of the fact that a multitude of similar problems already appeared on this board, however none of the solutions helped me.
I am trying to get Eclipse CDT running with MinGW toolchain on Windows 7 Service Pack 1. I already did that on Windows XP and thought that the same procedure will make it run smoothly on Windows 7, but it seems I was mistaken ;)
After installing MinGW from the automatic installer (just in case I installed a few things more than what I needed) and adding the C:/MinGW/bin to my PATH environment variable, I tried to compile a simple Hello, World! program. Eclipse did not give me any errors, but it didn't want to give any output in the Console window. Alarmed, I tried to run the executable file outside of Eclipse and got the error that
"Program can't start because libstdc++-6.dll is missing".
Strangely enough, this dll is in the C:/minGW/bin directory, so the PATH variable should 'find' it - but it does not. Copying the dll to the directory with the executable file helped, but it is obviously a short-term solution and I would prefer to have a more "normal" one.
The thing that makes my problem different, I think, from the others I've noticed on this board is the fact that, for one, Eclipse does not find any errors with my PATH variable (which it usually does, if the MinGW was not included in the Path variable or something), and besides the required dlls are where they should be, but it seems my Windows can't find them.

The "real" solution is indeed to copy the DLL locally. You have to ship that dll when shipping your EXE.

Related

Debugging fails with QtCreator on OSX

I have OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.

Visual C Run-time libraries missing

I've been losing sleep over this for a few days now:
I'm using SFML to create an application and everything was well until I created a new project a few days ago. After that whenever I tried to compile a solution that uses SFML libraries I would get linker errors and missing DLL files.
I looked around and found a program called dependency walker which looks at which DLL files a program depends on. Apparently my program executable was missing some DLL files that are meant to be inside the windows directory.
I freaked out just a little, before finding out they all had the prefix "CRT" and the suffix of either nothing or "D" which meant that they were Visual C run-time library DLL's.
Even though I'm not missing vital DLL's from my PC, I still need to fix this issue. No there was not major hardware/software changes to my PC prior to the problem (I don't have an antivirus and just trust my guts, I haven't had an issue for 5 years now) and yes I'm sure I'm setting up the SFML directories properly following a tutorial.
I've tried reinstalling and repairing VS and the redistributable VC's for my version of VS (which is 2012 express for win desktop), tried clean booting, the windows self file check (sfc /scannow) and also tried manually placing DLL's into my directory that the dependency walker said I was missing.
Has anyone else encountered this before? How did you solve it?
*Interesting note: I have access to an admin account on my school network and installed VS on a computer there to see if the problem would re-occur. Since the windows directories on those machines are never modified VS executed fine. Could it be that I need to get a clean installation of windows?
I'm not sure if OP is allowed to answer on his own thread (or if there is a time limit), but here goes:
I solved my issue after looking at it with a cool head. I re-checked the version of my SFML libraries and wasn't sure if they were 64 or 32 bit, so I re-downloaded the 32-bit version (because my debug compiler is set to run on 32-bit) that was compatible with my version of VS. This changed the error I got from missing MSVCP140D.dll to MSVCO120D.dll (the numbers correspond according to the architecture).
I Googled/asked around for a while more to figure out that I needed a file named MSVCR120D.dll, which was found in system32 but not in SysWoW64. After placing respective architecture DLL files (64 bit for system32, 32 bit for SysWow64) it finally worked!
Even though dependency walker still says the executable is missing 6-7 other DLL files, the project still compiles and runs fine.
I hope this wasn't a solution that only applied to me, I've seen many others with the same problem.

OpenCV in Code::Blocks: The application was unable to start correctly (0xc00000be)

I set up OpenCV with Code::Blocks as per this tutorial: http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/.
I've got as far as building the test program at the end successfully, but when I try to run it I get the following error: "The application was unable to start correctly (0xc00000be). Click OK to close the application."
The one thing that is certainly different from the tutorial for me is that I'm working with OpenCV 3.0.0, Code::Blocks 13.12 and the latest version of mingw (number not obvious from their website or the installer).
I found that other people had had this problem in the past, e.g. The application was unable to start correctly (0xc00000be)
However, it has been a long time since that thread was active, I'm working with newer versions of the software and, most importantly, the answer given there didn't help (I compiled openCV with the same mingw that I'm using with Code::Blocks), so I thought this question would be worth asking (sorry if it's not, I'm rather new to this).
Could anybody suggest a fix that might get rid of this error?
A few other things to note:
I didn't download the Code::Blocks that came with mingw as I was advised against it, I got them separately as per the tutorial
I have installed OpenCV and Code::Blocks on my E: drive, though mingw is still on my C:.
I have added both mingw and OpenCV to my PATH variable, and mingw to my Path variable
I have linked the libraries in both the main compiler settings for Code::Blocks and the Build Options of my project.
I'm working from a 64-bit Windows 7 Laptop, but I have done everything 32-bit style as advised in the tutorial.
Thanks in advance!
So, one solution I've found to this problem is to copy all the .dll files from "...\opencv\build\x86\mingw\bin" to the project file (build directory).
Having done that, the project will run fine. This still doesn't (directly) explain why it wont run without those files (at least, several sources including the tutorial imply it should), and so isn't really optimal. I will continue to look for a solution for this so I don't have to clutter every opencv project I make with the .dlls.
However, for anyone simply wanting to get stuck into coding who is having this problem, I recommend that solution.

Can't run C++ in NetBeans: "No Shell Found" error

I'm trying to learn C++ using NetBeans but even though I have CYGWIN and everything set up in my PATH, I keep getting an error that says: "No shell found. Cannot proceed. Please install either CYGWIN or Msys."
I don't know what Msys is but since the error says "or" I assume that if I have CYGWIN that I don't need to have Msys.
I'm trying to run the basic "Hello World!" tutorial but this error from what I've seen isn't covered. I'm getting aggravated because I have a project I need to have done in a few weeks.
If anyone has any answers for me, that would be great. I can supply screenshots if you need them.
Cygwin alone is not enough, first of all you have to check if you installed C++/gcc/gdb packages in your Cygwin.
From Cygwin/Net beans docs:
Open the Control Panel (Start > Settings > Control Panel) and double-click the System program.
Select the Advanced tab and click Environment Variables.
In the System Variables panel of the Environment Variables dialog, select the Path variable and click Edit.
Add the path to the cygwin-directory\bin directory to the Path variable, and click OK. By default, cygwin-directory is C:\cygwin. Directory names must be separated with a semicolon.
Click OK in the Environment Variables dialog and the System Properties dialog.
If it fails you could try to Re-Install Netbeans from/within an cygwin/bash instance start the netbeans from a cygwin/bash instance.
Netbeans should automatically detect gdb/g++
PS: I'd prefer to use a good Gnu/Linux distro
I had the same problem with 8.1.
Adjusting the %PATH%-variable - in my case adding C:\msys64\usr\bin - solved it (as wdavilaneto's slightly verbose answer suggested).
This is not an answer but it adds to this question, I know that isn't very objective but in this case there may be a problem with Netbeans. I have 7.3 so this could be the reason. I am getting the same error but it used to work just fine, then one day it just stopped working and couldn't find the Shell. I have everything you need to make C/C++ work for Netbeans and it was working, for a while too!
It is rather old, but I've had the same issue a moment ago. It "Solved itself" by Creating a new "welcome sample" project and then made it run, then went back to my original project and made it run again. For me, it solved the problem. Probably it is related to an issue with Netbeans as Cian said.
Btw, I'm with Netbeans 8.1.
Make sure the shell is in your path! Depending whether you have Cygwin, Mingw32, Mingw32, TDM Mingw... it will be somewhere here:
c:\<installation path>\usr/bin
Hmh, I have 2 C compilers one for 64bit and one for 32bit set in NetBeans. When I had 32bit compiler without 64bit one then compiling went fine but when I have installed 64bit then NetBeans has started to do some problems, firstly everything went fine but then I started to get this problem to. For me fix is to switch from 64bit compiler back to 32bit compiler, then compile my program and then go back to 64bit compiler and now I can compile it with 64bit compile... Not sure why is this fixing it.
I have this problem with Netbeans 10.
Computer is Windows 10 x64.
Resolved by following the answer given by TNT.
Problem was when start building my project the said "no shell" (the topic of this posting) dialog box popped up. Since there was no command prompt, the build tools cannot run - process cannot spawn.
Solution was to give the correct path (environment variable). Since I am using MSYS, Since I am using MSYS, adding
F:\msys64\usr\bin
to my PATH made it work.

Program only executes if I run it in Visual Studio

I have been trying to find a solution for this problem but I haven't been able to see/find any answer that correctly solves it.
I coded a program (Qt + OpenCV) that works fine when I run it with Visual Studio, but trying to run the executable it simply does not execute anything. The program doesn't give any error: it just never starts.
I am not sure where to start checking what is happening and why it is not even starting (I could understand lack of libraries, some other error..).
I am basically interested on what are the best way of checking why a program runs when executed from the IDE and not from the executable created. As I said, I was expecting an error message if something was wrong. Any ideas? Any good programming advice regarding how to avoid this problem in the future?
Edit: I forgot to mention that I am coding with a Windows XP machine. It doesn't work in this machine when I try to execute the file. It executes normally on a W7 machine but not in other W7 machine.
The executable will need the QT libraries on the computer that you are running it on. On linux there is command (I think ldd) that will show you what libraries your executable needs. I am not sure about Windows but there should be something similar. At least on a linux computer it will not necessarily give you an error if the QT libraries are missing. The executable just seems to do nothing.
Try copying the executable into the same directory as the .dll files in the Qt 'bin' directory.
If that works then you just need to put the Qt bin directory into your path, or copy the dlls into the windows\system directory
You need not only the correct dlls in your path (best in the application directory), but also the plugins in the correct location. See my answer to the question: Qt dll deployment on windows.