I have a simple HelloWorld application
#include <cstdio>
int main(int argc, char * argv[]) {
printf("Hello world\n");
while (getchar() != '\n') {}
return 0;
}
I compiled it with MinGW on Windows 7 with command
g++ -static-libgcc -static-libstdc++ HelloWorld.cpp -o HelloWorld.exe
In my computer it runs well, but when i move it to another computer with clean Windows 8, it doesn't start. After double clicking it, it shows "loading" cursor and it's loading and loading ... and never starts console and executes, no error message. The process is not listed anywhere in task manager and if i try to delete the exe file, it says it's being used by process System. Only restart makes it possible to delete this file.
What is wrong? How can i compile a program for Windows 8 and later on my Windows 7?
EDIT: i compiled the program with Visual C++ 2008 compiler and it does the same.
Related
Context
I'm not a huge fan of spamming StackOverflow with questions, but I've been trying to get this working for the past two days. Here goes...
I've come up with a small reproduction of a basic C++ file that compiles and runs perfectly on Linux (ubuntu), but compiles and results in an immediate SegFault (or constant access violation that seem to happen on the gtkmm event loop) on Windows 10 using the MSYS2 (mingw64) g++ compiler.
For MSYS2, I'm using the mingw-w64-x86_64-gtk3 package, recommended by the docs. My thoughts are that this is a problem during the linking process? No GUI appears, only terminal errors.
The line that causes the problem is specifically App::App : myLabel("HelloWorld") {.
By initialising the list inside the constructor using label = Gtk::Label("Hello world!");, the program actually works on Windows 10 as well, although I later found another segfault in another small detail.
I'm quite new to C++, my question is, am I doing something very wrong in my code or is it possible that the gtkmm library just isn't optimized for Windows, or that the binaries are out of date? I imagine that doing a lengthly compilation of the gtkmm source would work? Or am I just making a dumb pointer mistake?
Reproduction
MSYS2 setup:
$ pacman -Syu gcc mingw-w64-x86_64-gtk3
Compiled with:
$ g++ -std=c++11 `pkg-config gtkmm-3.0 --cflags` -o app app.cpp `pkg-config gtkmm-3.0 --libs`
The sample that segfaults:
#include <gtkmm/window.h>
#include <gtkmm/label.h>
#include <string>
// Class prototype
class Window : public Gtk::Window {
public:
Window();
Gtk::Label myLabel;
};
// Entry point, create app and initialise window
int main(int argc, char* argv[]) {
auto app(Gtk::Application::create(argc, argv, "ch.epfl.cemes.marcus.test"));
Window window;
return app->run(window);
};
// Extend Gtk::Window and show some text
Window::Window() : myLabel("Hello world!") { // this line seems to be the problem
add(myLabel);
myLabel.show();
};
Running the compiled executable of the code above on Windows results in the following error filling up the console repeatedly:
Exception code=0xc0000005 flags=0x0 at 0x0000000100401E9C. Access violation - attempting to read data at address 0x0000000021646CC2
My main application, that is practically identical but split into more files, exits immediately with the following:
Exception code=0xc0000005 flags=0x0 at 0x0000000063F14B9D. Access violation - attempting to read data at address 0xFFFFFFFFFFFFFFFF
0 [main] archipelago 1909 cygwin_exception::open_stackdumpfile: Dumping stack trace to archipelago.exe.stackdump
and yields a beautiful file with 15 lines of stack frames.
I appreciate the time you took to read this post. Have a great day!
Look in https://developer.gnome.org/gtkmm/stable/classGtk_1_1Label.html
Seems to me their constructor does not offer char* const parameter. Use myLabel.set_text("HelloWorld"); instead.
I have been told to make an exe file that will output 5 lines. I have been given these instructions:
Your program must not hang after running. I will execute it at command-line and will expect it to finish when the program is done.
I tried going to properties -> linker -> system - > console. It seemed to do what he wanted when I ran ctrl-f5. I then made an exe and now it disappears, and it doesn't print to the console.
I am using a simple cout program ex:
int main()
{
cout<<"hello"<<endl;
return 1;
}
Edit
I'm using visual studio 2013, and I am running from the command line.
Note I'm not asking for the window to stay open, but printing to the console itself.
I am not pressing ctrl-f5, but going to cmd.exe and then to the executable. I have tried the release version as well as the debug version.
If I have understood your question. Try following and add useful parts to your code. Not needed lines are commented out.
// ConsoleApplication1.cpp : Defines the entry point for the console application.
// (Just 2 ways to wait, befoore command-line console vanishes.)
#include "stdafx.h"
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
cout << "It's Foo's Bar!\n";
system("pause"); //preferred way.
//cin.get(); //2nd way, not as good.
return 0;
}
This question already has an answer here:
Trying to setup a C programming environment [closed]
(1 answer)
Closed 7 years ago.
Recently I decided to start coding again in C and C++, so I downloaded Dev-C++ and wrote the standard C Code for "Hello, World!" shown below:
#include <stdio.h>
#include <stdlib.h>
/* run this program using the console pauser or add your own getch, system("pause") or input loop */
int main(int argc, char *argv[]) {
printf("Hello World");
return 0;
}
Upon completion, the code compiled with 0 errors or warnings; however, I have a strange problem with running the executable. I'm writing and compiling on Windows 7 machine, and when I open the executable, the command prompt doesn't open to show the resulting program's text, which is what I was told would happen. Opening the Task Manager shows that there are three instances of the executable running at once, and they cannot be terminated with the "End Process" button. I've attempted to compile the same code in two different compilers (i.e. GCC, and Visual Studio) in C and C++ with the same results occurring in both additional environments. It may be worth mentioning that it's a home-build PC, but this is the only software issue I've encountered so far and the OS is a clean install.
Program may be hang if you use antivirus or windows defender. Please disable it and try again
The code below runs on windows ok and the trace but after transferring and building it on linux nothing comes out on the window. Here is the program (I've literally commented everything out after the trace output now):
int main(int argc, char const* const argv[])
{
std::cerr << "Hello" << std::endl;
return 0;
}
I kick the program off and nothing comes out. It builds without error on linux (and windows). The trace comes out in windows but I get nothing in linux.
This is a makefile issue. If I compile the program using g++ it works. If I use the makefile it doesn't work although it says it has built and linked without error.
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.