Cant run executables compiled by gcc on gc 4.8.2 - c++

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

Related

Linker hangs when compiling a simple eigen3 program on Win10

I am using the build tools provided by Rtools.
gcc version 8.3.0 x86_64-w64-mingw32 (Built by Jeronen for the R-project)
GNU ld version 2.33.1
eigen version 3.4.0
I have been testing various functions of the eigen package, and when I calculated the singular values using the BDCSVD object, the linker just hangs with full cpu usage. The following line is causing the trouble:
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
This line of code compiles fine. Just the particular linker does not return. I have waited a few minutes for the linker, but it just won't return.
On the other hand, when I used the latest gcc from the Windows Linux subsystem. Everything worked fine. So is this a known issue? Can it be easily fixed (but still using the build system provided by Rtools in Windows)?
PS: I have encounted this issue several times before, but the cpp files were much more complex, so I wasn't sure back then what caused the hanging linker.
Update:
A code sample is provided below. I configured my Windows copy of eigen3 using the "Unix Makefiles" option, since I do not have Visual Studio and don't want to download it.
Here is the cpp file:
#include <iostream>
#include <Eigen/Dense>
using namespace std;
using namespace Eigen;
int main()
{
double data[9];
for (int i = 0; i < 9; i++)
{
data[i] = i;
}
Map<MatrixXd> m(data, 3, 3);
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
auto v = svd.singularValues();
cout << "condition #: " << v.maxCoeff() / v.minCoeff() << endl;
}
I was trying to calculate the condition number of a singular matrix here.
Compiled using command line:
g++ -I"my eigen lib" t.cpp -o t.exe
where g++ comes from Rtools, "my eigen lib" is the eigen include directory, t.cpp the cpp file, and t.exe the build target.
Surprisingly or not, when I changed the algo from BDCSVD to JacobSVD, the compilation would succeed, even though BDCSVD defaults to JacobSVD for small matrices.
cc1plus and as both returned normally. ld keeps running forever, it seems.
Edits:
It's been awhile, but I am still looking for an answer.

String lower speed in mac and windows

Hello i have a program in c++ which add Hello world (50000000) times in front of string and i want to see toke how long. this is my source
#include <iostream>
#include <string>
using namespace std;
int main() {
string str2("Hello");
auto start_t = chrono::high_resolution_clock::now();
for (size_t i = 0; i < 50000000; i++) str2 += "Hello";
cout << chrono::duration_cast<chrono::milliseconds>(chrono::high_resolution_clock::now() - start_t).count() << " milliseconds\n" << endl;
return 0;
}
i checked this source in 3 Different situations:
Situation 1:
os: windows
ide: clion (latest version)
MinGW: 5
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
3100 milliseconds
Situation 2:
os: windows
ide: vistual studio 2017
compile: Release
and i got this result:
700 milliseconds
Situation 3:
os: MAC OSX
ide: clion (latest version)
CMAKE: 3.8.2
GDB: 7.11.1
c++: 17
compile: Release
and i got this result:
1200 milliseconds
i checked on windows and mac and i got this results... why? why the result are totally different? all the situations (Release mode and ...) are same!
Your comparisson has no stable basis.
You are comparing your code on different operating systems, with different compilers.
In order for a comparison to actually take place, you need to keep something fixed. For example, you could check with all three compilers in one system, OR in all three systems with one compiler.
Furthermore, try to use the same optimization flags on every compiler, so that they optimize the code in similar fashion.

-m32 flag not working to build 32 bit application

I am trying to compile some super simple code in Code::Blocks using GCC 4.4. I am on OS X Mavericks if that matters. I'm trying to compile and make a 32 bit executable, so I've taken the advice of a bunch of stack overflow posts to add the -m32 flag to the compiler (in Code::Blocks, I did Project > Build Options > Compiler Settings > Other Options > added -m32).
The code is the standard hello world program that pops up in every main file. I'll post it here for those who aren't familiar with Code::Blocks.
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
When I go to build, I clean all the object files and rebuild, and I get the following warning which prevents an executable from being created:
||warning: ignoring file obj/Release/main.o, file was built for i386 which is not the architecture being linked (x86_64): obj/Release/main.o|
I'm not really sure where to go from here. I thought the -m32 flag deals with these things.
Any ideas or directions I can take? If there's any info I left out let me know.

Compile 64-bit binary with MinGW (Dev-C++)

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.

Exe build by Code blocks is almost 57 times larger than the same code build by Visual studio

This code:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!\n";
return 0;
}
when comiled give size 457KB in Code::Blocks with GCC 4.4.1 and only 8KB (eight) in VS2010. Both compilers optimized for size.
Anyone knows why such a difference?
This is due to the c++ standard library being linked statically by g++, whereas VS will link it dynamically. A quick check using gcc under cygwin gives me approximately same sizes, and the resulting exe only import some C functions.
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0
}
On the other hand, this application compiled to the same minimal EXE under gcc, as it does not require any c++ functionality.
You are right, the executable by gcc is obviously larger, in your case 57 times larger than that built by vc++.
The main reason is the one made with
GCC won't require any external
dependencies to run while the one made
with VS2010 would need at least its runtime
files to be present on the system.
For instance, say you try it on some friend's computer with no vs2010 installed, rather try earlier OS like XP with no chance of having VS2010 runtimes even.
The one built with GCC will have no problems while the one made with VS2010 would throw an error of missing runtime file ( dependency ).
Hope this helped, if it didn't or you have any other question in your mind, feel free to ask and I'll be glad to help :)