I compiled my class Transfer correctly in Solaris. There is the executable file transfer. If i were in Linux, I would to ./transfer and the program would execute perfectly. However, when I run ./transfer in Solaris I get:
bash: ./transfer: invalid argument
Does someone know how to run an executable in Solaris?
Sounds like compilation was done targeting a different architecture than the host machine.
See related thread - x86 binary on a SPARC machine.
Please have a look at the follwing pages that I append here:
https://unix.stackexchange.com/questions/36376/what-does-invalid-argument-mean-in-solaris
I am trying to excute java from solaris, getting invalid argument error
and also consider correct folder of files and file permissions, sometimes these issues can make problems.
Related
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.
I wrote a program in Turbo C++, and compiled it there. Everything was successful, and the program ran as expected. Now, I want to run the program as an exe file. I found the exe file in a separate folder named 'Source'. But whenever I try to run it, I get the error :"This app can't run on your PC. To find a version for your PC, check with the software publisher." None of the exe files in that folder are working, although all the other softwares (like Photoshop) are opening fine.
Could someone help me please?
The OS on your PC probably is 64 bit. So the older 16 bit application would not run on it. I suggest you to use some virtual machine with installed OS DOS (or free DOSBOX for example), or try to compile your program on more modern compiler.
write
system("PAUSE");
before return 0;
I'm a beginner with programming, and I've been doing work in C/C++ in Ubuntu. When I tell something to cin/cout/cerr or printf/scanf or take arguments from the command line, this all happens from the linux terminal in Ubuntu.
Now if I want to run these same programs (very simple programs, beginner-level) and run them in Windows, how do I run them from the Windows command line? A previous course I've taken had us download cygwin to simulate the linux command line in windows, but what if I want to just run the program from the ordinary windows command line? Is that possible, and does it require modification of the software?
You can cross-compile the program for Windows from linux.
On Ubuntu, process is basically this:
sudo apt-get install wine mingw32 mingw32-binutils mingw32-runtime
...
i586-mingw32msvc-g++ -o myProgram.exe myProgram.cpp
Easy, right? Google for "ubuntu cross-compile windows," there's a ton of information out there.
It's exactly the same. You run cmd and write the command (almost) exactly as you would in Linux.
For example, if you build your program to program, you would run it in Linux like this:
./program --option1 -o2 file1 file2
And in Windows, first you have to make the output have a .exe suffix and then in cmd you would write:
program.exe --option1 -o2 file1 file2
Basically saying, cmd is Windows' terminal. It's nowhere near as good as the Linux terminal, but that would be all you get without installing additional software.
cin/cout/cerr and printf/scanf/fprintf(stderr, ...) use the standard C preopened files stdin, stdout and stderr which are defined both in Linux and Windows. Once you run the application from Windows' terminal (cmd), you see the input/output exactly as you would in the Linux terminal. I/O redirection is also very similar.
cin and cout, and printf and scanf, work much the same in Windows as they do in Linux. (I'm pretty sure cerr does too, but that one i'm not 100% sure about. At the very least, though, it's there and works.) The biggest difference is that Windows typically won't expand wildcards (stuff like *.txt) before running your program; you have to do that yourself in most cases.
Basically, as long as the app doesn't use anything specific to Linux or GCC, you could just recompile it on the target machine using whatever compiler you like to test.
If you don't want to recompile...well...good luck with that. Even Cygwin won't run native Linux binaries. You'd need a virtual machine with Linux on it.
Well, if you program is portable and not using any features specific to Linux, you would have to compile it from source on Windows to make it work on Windows.
You would need the GCC tool-chain for windows to do that, which you can get from the TDM-GCC homepage. Its MinGW internally and the installer allows you to choose the features you want to install as well as the target directory for installation. It also adds itself to Windows path so that the compiler commands are available from the shell prompt.
I have to do the cross compilation regularly and it works without any issues for me. There is one change which you must make if your project is using Makefiles. For the target binary, such as <target>.out in linux, you would have to edit your Makefile and rename it to <target>.exe so that it runs on the command line. If you are not using Makefiles and just doing gcc <file.c>, the a.exe is produced by default (similar to a.out in Linux).
Say you have this program code you want to run on UNIX and Windows:
#include <stdio.h>
int main()
{
printf("Hi\n");
return 0;
}
When you type a command in a UNIX shell it will be something like this.
/usr/home/bobby# gcc main.c
/usr/home/bobby# ./a.out
Hi
/usr/home/bobby#
On Windows you'd have to first choose your development environment/compiler. Without going to something like Cygwin, you could install the Windows SDK or Visual studio (although if the latter you might just want to develop in the GUI).
Start -> Run -> cmd /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
C:\Windows\system32>cd c:\bobby
C:\bobby>cl main.c
C:\bobby>main.exe
Hi
C:\bobby>
When a C program is compiled into an executable this is done in a system dependent way. On Ubuntu the ELF format is used and on Windows we have PE.
When you start a process the ELF or PE is read giving instructions/map on how to allocate memory and where to put various pieces of the process in a virtual memory table. Further it links up to dynamically loaded libraries, already in physical memory, that it share with other processes which is using the same libraries. Or if the dynamic libraries is not present load them. (Linux .so, windows .dll). If it has static libraries these are allocated and linked in (Linux .a, Windows .lib). - Very simplified.
Memory restrictions etc are inherited from previous process.
Environment variables are put into the running environment for the process. This being paths, arguments, etc. Then main() is added to the stack and called.
Now everything happening before main is called and how linkage etc are resolved, and so many other things, depends on the system. This is why one simply can't run an executable compiled on Linux on Windows.
Using cygwin one is simply creating a virtual environment where those linkages etc are the same and would work. One create an ELF environment.
To get it linked for native Windows command line one would have to compile for Windows. On that matter I see there is lots of answers already.
The ELF and PE, as on different systems, also have different ways of handling environment variables etc. What these are etc. So i.e. file expansion is handled differently. However both running processes has the default streams like stderr, stdout and stdin. But below your code in C they are not the same.
It is like driving a diesel vs a petrol car. Much is the same but under the hood quite a few things is different.
Be aware that i.e. signals are handled different on Windows.
I was auditing Stanford cs107 and unable to get the assignment files (which could be found here http://see.stanford.edu/see/materials/icsppcs107/assignments.aspx) working on my Mac or PC. I tried to run it on Ubuntu through VM, it didn't work either.
In assignment 1, the file rsg-sample-linux shows not executable, unlike it is on the assignment PDF file. After I used chmod to change it to be executable, the terminal on my Mac says "cannot execute binary file", and Ubuntu says "no such file directory" something like that.
I really want to go through all the assignments while auditing this class
Thanks!
Since these are binary files there is no guarantee that they run on your system. rsg-sample-linux is for 32 Bit systems, so if you have a 64 Bit system and missing some compatibility library, it won't work.
Therefore you cannot avoid typing in make and built the rsg on your own.
I have been trying to find a solution for this problem but I haven't been able to see/find any answer that correctly solves it.
I coded a program (Qt + OpenCV) that works fine when I run it with Visual Studio, but trying to run the executable it simply does not execute anything. The program doesn't give any error: it just never starts.
I am not sure where to start checking what is happening and why it is not even starting (I could understand lack of libraries, some other error..).
I am basically interested on what are the best way of checking why a program runs when executed from the IDE and not from the executable created. As I said, I was expecting an error message if something was wrong. Any ideas? Any good programming advice regarding how to avoid this problem in the future?
Edit: I forgot to mention that I am coding with a Windows XP machine. It doesn't work in this machine when I try to execute the file. It executes normally on a W7 machine but not in other W7 machine.
The executable will need the QT libraries on the computer that you are running it on. On linux there is command (I think ldd) that will show you what libraries your executable needs. I am not sure about Windows but there should be something similar. At least on a linux computer it will not necessarily give you an error if the QT libraries are missing. The executable just seems to do nothing.
Try copying the executable into the same directory as the .dll files in the Qt 'bin' directory.
If that works then you just need to put the Qt bin directory into your path, or copy the dlls into the windows\system directory
You need not only the correct dlls in your path (best in the application directory), but also the plugins in the correct location. See my answer to the question: Qt dll deployment on windows.