I have successfully built OpenCV and I have come to the point where code::blocks recognizes the OpenCV syntax and successfully builds the program. However when I run I get this error
"The procedure entry point_gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll."
I am using Code::Blocks v 12.11 and minGW (the most recent, I can't remember the version number) along with OpenCV-2.4.8 Has anyone ever seen this problem? Help if you can, anything right now might work since I am so close.
https://stackoverflow.com/questions/3895879/installing-opencv-on-windowsw32-to-be-used-with-code-blocks?rq=1
Using this link to the other question I was able to locate a hint for my problem. I had everything correct and the hint to change the build to a GUI Application solved the issue. The programs build and then run as they should.
Related
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.
So, I'm using CodeLite on Windows, building with Mingw64 on 64 bit system. Everything builds, but when i run the application, it crashes with "Client.exe" has stopped responding. Client.exe being my application. I'm literally running the default example code off the SFML website. When I've googled around for quite some time now and I honestly have no idea as what to even look at for this error.
Sometimes my console will output
Application has exited with error code: 255
But most of the time it outputs:
Program exited with return code: -1073740940
Using help from the comments on my question.
As stated by Satus, The issue was, first, my libraries were statically linked, using the Dynamic libraries, instead, seemed to have fixed my issue. My second issue was that my SFML libraries were built using the wrong version of MingW. Recompiling this was simple enough. I downloaded the SFML source code. Used CMake to set everything up as displayed on the official SFML compiling and building tutorials, and built it using my version of MinGW. After copying the newly compiled DLL's and Debug DLL's, everything worked perfectly.
Be sure if you're using two different version of MingW (64bit and 32bit) to compile each version in CMake accordingly, otherwise you may get issues.
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.
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.
I'm trying to build the Windows version of my app. The program compiles and runs fine on Qt Creator but when I try to run it standalone it throws the following error:
The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not be located in the dynamic link library QtCore4.dll
I have all the necessary dlls in my application folder and they are the same ones that came with the binaries I've downloaded from the Qt's website. This error is driving me crazy for I can't seem to find any reason for it. The application runs fine on Linux and MAC OS X.
Ok I found the problem. I was copying the wrosng dll (not sure why Qt ships with 2 different versions).
The right ones are in:C:\Qt\2010.05\qt\bin and NOT in C:\Qt\2010.05\bin
I hope this helps anyone who might stumble upon this issue.