-m32 flag not working to build 32 bit application - c++

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.

Related

Content of directory messes with how the code runs even though there's no reference of it

So I spent 2 hours trying to narrow down the cause of my code not working and I think it might just be something weird. Here's the exact example code I have and I can't minimize it further (yes, bar does literally nothing) :
// thread example
#include <iostream> // std::cout
#include <thread> // std::thread
void bar()
{
// do stuff...
}
int main()
{
std::cout << "please run" << std::endl;
std::thread t(bar);
t.join();
std::cout << "completed.\n";
return 0;
}
Here's how I build it :
g++ -std=c++0x -o test test.cpp -pthread
When all of this is done in a blank directory, it works perfectly, but if I put test.cpp in my project directory, compile it here and run it, it crashes before even entering main. Here's the crash report but I translated it from French so it's not the exact text:
"The entry point of the procedure std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) cannot be found in the library of dynamic links [project directory]\test.exe"
Note that this message did not appear in the console command but in a separate window pop-up from where I can't copy-paste.
Here's what's the project directory is (not quite exactly because script files were updated but it's the same structure and libraries) : https://github.com/Leroymilo/RTX_Cpp
It has SFML and jsonCpp in it if it changes anything.
Also I am on Windows10 and I'm using VScode if it makes any difference.
I did what's advised in this post : Segmentation Fault while creating thread using #include<thread> but it does not change the result.
The issue was the presence of a file called "libstdc++-6.dll" in my project directory. I have no memories of why it's here because I copied all libraries from another project but if anyone does the same mistake, here's your solution.
Edit : I found out about why I had this in my files : it's because my build wasn't static and launching the built executable on another computer showed a pop-up asking for these. I fixed my static build issue with the answers provided in this post : Issues with libgcc_s_dw2-1.dll and libstdc++-6.dll on build .

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.

Eclipse C++ Setup

I want to switch from Dev-C++ to Eclipse (Version 12/18, 4.10.0) , but I am not able to Compile in Eclipse. I installed MinGW, edited the Pathvariable, restared the PC, installed the C++ Eclipse IDE, created a new Project there I choosed MinGW as my Compiler, and wrote a Hello World.
The Code is:
#include<iosteam>
using namespace std;
int main(){
cout << "Hello World!";
return 0;
}
The Error Message I get is the following:
error: CreateProcess: No such file or directory
What do I need to do to be able to build/run Proramms?
Thanks in advance
You have everything you need to be able to build/run programs. Maybe something is flawed in the configuration. You should separate the tasks to find out the problem.
First try to compile your minimal example by executing g++ from a console like that:
g++ main.cpp. If you get the same error message then you have to fix your Mingw-w64 setup.
If this works, then something is wrong with eclipse. You might want to check different project types. When using Makefile projects, you perhaps have more possibilities to do checks on the console.

"undefined reference to `WinMain#16'" Error in gcc editor

I am just learning c++ and began to watch a youtube tutorial by thenewboston. Unfortunately he is using Code::Blocks while I am using gcc and I do not have the option to create new class files with a button click and so had to manually create them.
I dont understand why the same code in Code::Blocks and gcc will work in Code::Blocks but not gcc. Does gcc require different coding for the same language?
EDIT: I have downloaded and tested in Code::Blocks myself
Other questions talk of how I need to give windows an entry point, but I dont know how to do that.
Test.cpp Code:
#include <iostream>
#include "ClassTest.h"
using namespace std;
int main() {
ClassTest bo;
}
ClassTest.h Code:
#ifndef CLASSTEST_H
#define CLASSTEST_H
class ClassTest {
public:
ClassTest();
};
#endif // CLASSTEST_H
ClassTest.cpp Code:
#include <iostream>
#include "ClassTest.h"
using namespace std;
ClassTest::ClassTest() {
cout << "blah blah" << endl;
}
I'm not quite sure I understand what the question is; I'm going to take it as "how do I get these three files to build into a .exe that I can run from the Windows commmand line?"
The answer is to run something like this on the command line, in the folder with the files:
g++ -c Test.cpp -o Test.o
g++ -c ClassTest.cpp -o ClassTest.o
g++ Test.o ClassTest.o -o Test.exe
The first two commands build each CPP file into an "object file", which isn't a whole program by itself but which contains the compiled version of the code in that CPP file. The last command tells the compiler to paste together the two object files into a program, and resolve all the cross-references between them. (For example, the part where Test.cpp constructs a ClassTest object needs to end up calling the ClassTest constructor code from ClassTest.cpp.)
Code::Blocks is an IDE and works out how to build each source file in your project and link them together by itself. But if you aren't using an IDE, you need to do that in another way. You can either do it manually like this, or you can write a Makefile that will check which code files have changed and rebuild and re-link everything that depends on them when you run the make command, which is how most people do it.
As for "giving Windows an entry point", that probably refers to GUI applications that want to display windows on the screen. For console programs like the one you have written, the "entry point" is main(), and you just print stuff to the command line window. To make actual Windows-style GUI windows of your own, you need to use the Windows API, which I can't tell you much about.

MinGW completely bugged on NetBeans

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!