This question was migrated from Super User because it can be answered on Stack Overflow.
Migrated 15 days ago.
I am trying to write a very simple ncurses program, just to play around with, using mingw-w64 on Windows 10. I installed the mingw-w64-x86_64-ncurses package with pacman, and am using the MSYS2 MinGW64 environment terminal. I have no experience with any curses library and very little experience in general developing software on Windows.
I have written the following hello world program in Main.cpp:
#include <iostream>
#include <ncurses.h>
#include "Headers.hpp"
int main(int argc, char ** argv) {
initscr();
printw("Hello World!");
refresh();
getch();
endwin();
return 0;
}
I compile this with the following command:
g++ -I /C/msys64/mingw64/include/ncurses HelloWorld.cpp -L/C/msys64/mingw64/bin -lncursesw6 -o main
It compiles, but when I run main.exe, I get
Error opening terminal: xterm.
Why does this happen, and how can I fix it?
The MInGW build works for Windows console (see README.MinGW). Other platforms use $TERM. msys2's mingw32 and mingw64 configurations are used for targeting the Windows console. Use the msys2 configuration if you want a program to work in that configuration.
The Windows Console API uses function-calls rather than writing characters (and escape sequences). This is different from mintty (used in msys2), xterm, Windows Terminal.
Further reading:
Using the Console
Console Functions (Windows Console API)
I had similar problem using the ucrt64 environment on msys2. Seems the proper configuration for xterm can not be found. Try:
export TERM=xterm
export TERMINFO=<path_to_ncurse_build>/share/terminfo
./my_program.exe
It should work. Have good coding!!!
Related
I'm using g++ on WSL Ubuntu. I cloned the GLFW repo using git, used the ccmake command to configure and generate the binaries, then used make inside the "build" directory to finally create the .a file. I installed all the OpenGL-related libraries to /usr/ld (I don't recall exactly which I installed, since I had to install so many. Regardless, the g++ command works, so I assume it was a success). Afterwards, I made a project on VS Code that looks like this:
The GLFW include-folder is from the aforementioned cloned repo, and the GLAD and KHR include-folders are from glad.dav1d.de, where I set the GL version (under API) to 3.3, and the Profile to Core.
In main.cpp, I put a simple snippet of code meant to initialize GLFW:
#include <iostream>
#include <glad/glad.h>
#include <GLFW/glfw3.h>
int main()
{
// Initialize GLFW
if (!glfwInit()) {
std::cerr << "Failed to initialize GLFW" << std::endl;
return 1;
}
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
std::cout << "Success" << std::endl;
return 0;
}
Then used this to command to compile the project: g++ -Wall -I./include/ -L./lib/ src/*.{c,cpp} -lglfw3 -lGL -lX11 -lpthread -lXrandr -lXi -ldl -o main. There were no warnings or errors or anything. After running the executable, I get the error message that GLFW failed to initialize. I was a little confused why this happened, so I typed the glxinfo command to find out that my DISPLAY environment variable hasn't been set.
I have absolutely no idea what this variable is, or what it's meant to represent. After scouring around on the internet, I came across export DISPLAY=:0.0 and export DISPLAY=1 and export DISPLAY=IP:0.0, none of which worked. Any ideas on how I could resolve this?
WSL on Windows 10 does not include support for GUI apps. You can build an app with OpenGL/X libraries, sure, but running it requires an X server on which to actually display it.
In general, you have 3 options. I believe all of these will work with OpenGL, although I have not tested each of them in that capacity:
The "supported" method is to use Windows 11 with WSLg. Windows 11 supports hardware-accelerated OpenGL in WSL2 out-of-the-box using a supported WDDMv3.0 driver (available for AMD, Intel, and nVidia GPUs). See Microsoft Docs for more information.
The "normal" method of running an X server on WSL with Windows 10 is to install a third-party X server such as VcXsrv. See this Super User question for some details on OpenGL support under that scenario. I don't believe that this will be hardware-accelerated, however.
You'll need to manually configure the DISPLAY variable in this case to point to your Windows host. You'll find some fairly complicated directions for doing so, but IMHO the easiest way is via mDNS.
Before upgrading to Windows 11, I used xrdp when I needed X support. This allows access to the WSL instance using the Remote Desktop Protocol and supported apps like the built-in Windows Remote Desktop Connection. I don't believe there is a way to hardware accelerate OpenGL using RDP, either. In my opinion, this is far easier than setting up a 3rd party X server. See my answer on Ask Ubuntu for steps to enable.
WSL 2 now has support for GUI apps on Windows 11:
https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps
I had just installed the GPU driver, updated WSL, and now it works for me.
I wrote a simple code and compiled using g++ in linux in .exe format, suprisingly it got executed in my linux terminal. Can u say the reason for this ? Can linux terminal execute machine code in any format ? Can I run the same in windows ?
Code :
#include<iostream>
using namespace std;
int main(){
cout<<"Hello World !"<<endl;
return 0;
}
Compile code:
g++ main.cpp -o program.exe
OS: Linux Mint 20 Cinnamon.
I execute by typing ./program.exe
Q: I wrote a simple code and compiled using g++ in linux in .exe format, suprisingly it got executed in my linux terminal
A: There's nothing "surprising". I assume you compiled it under Linux? So why shouldn't you be able to run it under Unix?
Q: Will an .exe I build on Windows run on Linux (if I copied the binary)? A: Short answer: No.
Longer answer: you can install Wine to run Windows applications on Linux.
Q: Will an .exe I build on Ubuntu run on Windows? A: No.
Q: Does an executable I build on Ubuntu need to have the suffix .exe? A: No. File suffixes are irrelevant.
Q: Does an executable I build on Windows need to have the suffix .exe? A: Yes.
To answer your additional questions:
There are many reasons why an .exe built for one platform cannot load or run on a different platform.
Sam Varshavchik put it well:
It's for the same reason a radiator for your Toyota won't fit into a
Dodge
More to the point, an "executable image" is much more than just "the machine code".
An .exe is an example of "executable images". They come in many different formats: https://en.wikipedia.org/wiki/Category:Executable_file_formats. Most of these formats are platform-specific.
Any image must be loaded by the operating system in order to become a running process. This, too, is platform-specific.
The running process will need resources like file I/O , memory and shared libraries, which are also platform-specific.
I hope that helps...
Since you compiled the code using g++ on Linux, you should be able to run it on Linux but it won't work on Windows because the binary executable is compiled for Linux.
On Windows, .exe is the extension of the executable file but the binary code must be compiled for Windows so that it can run. On Linux, you can use any extension, .mp4 or anything and it will still run when typing ./program.mp4 in terminal.
G++ fails to compile simple "Hello World" code.
Platform details are in the Title
I have tried to run from both VS Code ("insiders" version 1.26.0), and from the Windows command-line /terminal.
Neither route will return an *.exe file
This is the C++ code. VSCode Intellisense doesn't show any errors (C++17)
#include <iostream>
using namespace std;
int main()
{
std::cout << "Fresh New World" << std::endl;
return 0;
}
At the Windows command line (terminal) I've used the command
g++ -o FreshWorld.exe FreshWorld.cpp
This command does not return an error, nor does it return the desired *.exe file (I've even resorted to SEARCHing all the folders)
Running this in VSCode (1.26.0) also does not return an error.
I had run this code in the previous stable release (pre- "June 2018") VS Code, and it compiled properly. The problems started immediately after the update to Jn2018. I've worked with VS Code developers (that's why I'm running the "insiders" version) but, as we now know, the problem also exists at the command-line (terminal) so not confined to VS Code.
Any ideas??????
I am entire newbie to C++, MinGW, and to VS Code so this has become an insurmountable hurdle to further experimentation and learning!
Lots of things could be causing this:
Antivirus: it could be intercepting the gcc executable (they tend to dislike other compilers due to the way a compiler generates executable code etc.). Try disabling the antivirus and test again.
Your MinGW(-w64) installation is broken. Try reinstalling. Where are you getting your GCC? I strongly suggest using something like the official MinGW-builds for MinGW-w64 here or a package management system such as MSYS2.
Wrong environment settings. Your provide little details of how and what you are doing (how are you starting the command prompt interpreter, how is your PATH set up, etc.).
Without more details, I can't determine what is going wrong for you. Please edit your question to provide these details.
I'm a new user of MinGW, and I have already run into problems. When attempting to compile a very simple Hello world c++ program, I get an error. I type the command:
g++ hello.cpp -o hello.exe
and then I get the message dialog:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: c:\mingw\bin\...\libexec\gcc\mingw32\4.8.1\cc1plus.exe
R6034:
An application has made an attempt to load the C Runtime library incorrectly.
Please contact the application's support team for more information.
followed immediately by this message dialog:
cc1plus.exe - Program error
The application failed to initialize properly
(0xc0000142). Press OK to close application.
And then the usual junk about Windows finding a solution online.
I used the automatic installer mingw-get-setup.exe and simply followed the instructions. I chose the installation folder to be C:\mingw, and in the MinGW Installation Manager, I chose to install mingw-developer-toolkit, mingw32-base, mingw32-gcc-g++, mingw32-gcc-objc and msys-base. As suggested in the installation guide, I added PATH in the Environment Variables.
The code I was trying to compile was:
#include <iostream>
using namespace std;
int main(int argc, char ** argv){
cout << "hello world" << endl;
return 0;
}
I also tried to compile a similar ANSI-C code with the command:
gcc hello.c -o hello.exe
and I got the same error.
I tried the command in cmd.exe as well as in MSYS and got the error in both cases. My operating system is Windows Vista Home Premium, and I have Microsoft Visual C++ 2010 installed on it. I mention this because I tried to do the same installation on a windows 7 computer without VC++ and here the compiler worked without problems. Does this mean that you can't have MinGW and VC++ on the same computer?
The problem was, as suggested in the comments, that programs other than the Gnu Compiler had left values in the %PATH% variable. What I did not initially notice, was the fact that there are two %PATH% variables, one for the user and one for the system, and both can interfere with the MinGW installation.
The system %PATH% variable contains (at least on my PC) quite a lot of entries and removing all of them might not be a good idea. In my case, however, it was sufficient to remove entries from MatLab and Texnic Center. Afterwards, g++ and gcc worked flawless.
I've got an application in Code::Blocks, and it's the simple Hello, World traditional program.
#include <iostream>
int main() {
std::cout << "Hello, World!" << std::endl;
}
The program builds and executes, but the output isn't shown. I checked the project properties in Code::Blocks and it is definitely set to console application. Any suggestions as to the problem?
Edit: The output only fails in the IDE. When run separately the resulting executable functions exactly as expected.
It's possible that you don't have xterm installed it.
If you are on Linux (Debian flavor) you can install it with your package manager like so:
sudo apt-get install xterm
Maybe you need to set the terminal to launch the console applications. It can be done in the general environment settings.