It is probably a stupid question but i was searching for the answer from about 3h.
¿How to compile 64-bit binary with (Dev-C++) MinGW?
I have readed that MinGW support 64bits by default, but i am unable to active this option.
I have tryed "-m64" but it say: "sorry, unimplemented: 64-bit mode not compiled in"
I am working on Dev-C++ on Windows-7
I know how to do it on MSVC++, but I don't want MSVC++ (cause of ethical issues)
What i am trying to compile, just for testing purpose:
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
// Test compiling mode
if (sizeof(void*) == 8) cout << "Compiling 64-bits" << endl;
else cout << "Compiling 32-bits" << endl;
return 0;
}
To build a 64-bit binary on windows you need the 64-bit version of the mingw compiler. Mingw-W64 is one possible distribution you can use. You can find a list of downloads here.
Additionally, you can also find Dev-C++ setup bundled with mingw 64-bit compiler under Orwell Dev-C++'s download section. Make sure you choose "TDM-GCC x64 4.7.1" either setup or portable.
Related
I have a program that is written in C & C++ and I'm rewriting some parts to improve it. This program has to work with files, but I am not able to check if a file exists on Windows with a cross-compiled exe.
To check if my code was the problem, I have created this simple example:
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
if (in_file) {
std::cout << "File exists" << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
Compiling this code using "x86_64-w64-mingw32-g++", version 8.3-win32 on Debian 10, I'm unable to check if a file exists because it always returns "true". To verify it I have compiled the same program on Linux using g++, and on Windows using mingw64, and both were working so looks like a problem building the project on Debian 10 mingw32.
I don't know if my problem is a bug on Debian version or I am doing something wrong. Anyone knows anything about it?
The only difference I have seen between both, is the version (8.1 on Windows vs 8.3 on Debian), and of course the SO.
Thanks!.
EDIT:
I have upgraded to Debian 11 which has the x86_64-w64-mingw32-g++ v10 and same behavior. I forgot to say that I am using Debian 11 on WSL, not a real Debian distribution. I don't think it matters.
EDIT2:
I have already seen the suggested thread, but the problem is that I want to use streams to manage the files and the only option in that thread also fails. Using any of the other three ways will be like a hack that will not help too much. I think that is not the best way to check the file presence with another example, and then reopen the file later to work with it.
Is supposed that the fstream class have boolean conversion as I have read in several threads and that is why I'm using this example. The Linux version works perfectly, so the function is working as expected. The problem is the Windows version compiled in Linux (cross compiled EXE).
I have tested in_file.good(), in_file.is_open(), in_file.bad(), just in_file... all of them returns like the file was open correctly. Also I have tried ifstream, but same behaviour.
Rest a bit always helps... I have found a workaround to my problem just reading 0 bytes.
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
char dummy;
if (in_file.read(&dummy, 0)) {
std::cout << "File exists " << in_file.tellg() << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
With this, even the cross compiled EXE works without problems.
I still thinking why only fails with the cross compiled EXE, but I was not able to find any info about it and how to fix it. At least this solution is working.
Best regards.
The following code shoudn't produce an error:
#include <cstdlib>
#include <cstdio>
#include <iostream>
using namespace std ;
int main ( int argc , char** argv )
{
int n ;
cin >> n ;
cout << n ;
return 0 ;
}
Yet a get a "RUN FAILED (exit value -1,073,741,511, total time: 46ms)" whilst running MinGW/Msys on Netbeans. Any advice like switching back to Cygwin?
I recommend using MinGW Distro if you want to develop C++ under a Microsoft Windows operating system. It ships with a pretty new GCC version and with the Boost libraries.
NetBeans IDE is pretty picky regarding the build environment settings. E.g. It doesn't work together with all versions of make (we have to distinct make.exe from MSYS and mingw32-make.exe from MinGW for example) and there are problems regarding the used Java Runtime Enviroment (JRE).
With the settings shown in the following screenshot you should be able to build your example with MinGW Distro and NetBeans 8. I recommend to not configure a absolute path to the make.exe file but add that path to your Microsoft Windows environment variable PATH. Otherwise you may get build errors.
Maybe these two blog posts help if you want to use the "default" MinGW distribution:
Installing Minimum GNU for Windows (MinGW)
Configure NetBeans IDE for Minimum GNU for Windows (MinGW)
I hope this helps others as well.
Not related to your question: Don't use using namespace std:
#include <iostream>
int main(int argc, char** argv) {
int n;
std::cin >> n;
std::cout << n;
return 0;
}
I ran into this same issue (with exit code -1,073,741,511), so though a dated question, I'm posting this here for anyone else who runs into the problem.
Run the executable for the program manually. You might get an error such as "the procedure entry point __gx_personality_v0 coud not be located in the dynamic library libstdc++-6.dll". (OP has confirmed this in a comment.)
The .dll file referred to in the error message above is either not being linked, or linked incorrectly. The correct version of the .dll that needs to be linked is the one in the ...\MinGW\bin directory. In Windows, you can check the .dll file being linked by typing where libstdc++-6.dll in a command prompt; the first result that is listed will be the file that is linked. If you already see ...\MinGW\bin\libstdc++-6.dll as the first result here, my fix below will not help you.
If you see a message "INFO: Could not find files for the given pattern(s).", then ...\MinGW\bin needs to be added to your %PATH% variable. (OP has already confirmed this was not the issue.)
The issue I was having was that a program I had installed had its own (likely outdated) version of libstdc++-6.dll, which was in a folder also included in my %PATH% variable, ahead of ...\MinGW\bin. This meant that this other .dll file was being picked up and linked to during execution. This can be fixed by editing your %PATH% variable to make sure the ...\MinGW\bin entry is ahead of all other directories that also have a version of the .dll file.
Edit: The other option is to statically link the .dll at program compilation, or place a copy of the correct .dll in the program executable directory. However, neither of these fixes is 'global', and needs to be done for each project individually.
Hope this helps!
I did a fresh installation of minGW on windows 7 64 bits, I can compile c++ without errors, however if I try to run the executable, I get
"This version of D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether ou need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
My code is
#include <iostream>
using namespace std;
int main() {
cout << "aaaa" << endl;
return 0;
}
and I'm compiling using
C:\MinGW\bin\gcc -c D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.cpp -o D:\xampp\htdocs\Dropbox\Dropbox\c\rts\teste\a.exe
I believe GCC is not compiling 16 bit software, since its the last release
I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.
#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}
This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.
Has anybody seen this problem.
Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.
Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:
Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()
In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.
I suggest the following experiments:
1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):
#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}
2) Eliminate the exit code by:
int main()
{
return 0;
}
3) No newline at all:
#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}
4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).
I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.
I have googled the error for hours on end now and have not gotten much of anywhere. I have linked the project in my Visual Studios (2010 & 2012) project as that seems to have resolved everyone else's issue that was similar to this. However I am still unable to get my sample code from boost's website to work and keep getting that error. The file libboost_filesystem-vc100-mt-gd-1_47.lib is in my C:\Program Files (x86)\boost\boost_1_47\lib path. Here is the code I am trying to test and get boost up and running.
#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
int main(int argc, char* argv[])
{
if (argc < 2)
{
std::cout << "Usage: tut1 path\n";
return 1;
}
std::cout << argv[1] << " " << file_size(argv[1]) << '\n';
return 0;
}
Enter:
[boost_path]\stage\lib
In setting under Linker->General->Additional Library directories.
As mentionned by SChepurin it could be that you didn't add the path to boost to Linker->Additional Library Directories.
It could also be the case that you are trying to compile for x64 target whereas, given the install path for your boost libraries, you have only the 32 bits boost libraries installed on your system and therefore should either switch to x86 target or get 64 bits boost libraries, You can find binariy release from Boost 1.50 if you can use a moe recent version than 1.47 otherwise you will have to compile them yourself (see boost official documentation for more info on that)
Best
I had the same error and i followed the SourceForge. The link will take you to a folder of zipped lib and dll files for version of boost.You can download and unzip related library and when copied it to the related location everything gonna be alright ;)