If I had some source code in C# and I wanted to compile binaries intended to run on Linux, I would specify some CLI options indicating the build target and whether to bundle supporting files.
How do I go about doing the same thing for code that compiles for Windows using gFortran? I need to figure out how to build the same thing for Linux.
Is there some kind of compiler switch and if so what is it called? I have found the gFortran documentation web but the concepts are differently organised and the nomenclature is very different.
There is also a more specific question attending this. According to this answer to another question: Standard input and output units in Fortran 90? stderr, stdin and stdout have the values 0, 5 and 6 respectively. Are these constants consistent across platforms — can the values change depending on whether you're compiling for Windows or Linux?
Related
Say I developed a simple software using C++, and I want to distribute it for free. For simplicity sake assume it is some sort of GUI. Now when I compile it on Windows and run the .exe, it works as intended. However, the end user might have a different version of Windows then I do. So the .exe file may not run because of differences in machine code or instruction set (I think?) In these situation is it common practice to include the compiler to the end user so that the compiler is built and then my source code is compiled or do I use a cross compiler instead? Or how is it commonly done? Sorry for the stupid question.
I know that for running c++ on Windows you need to compile specifically for Windows and the same goes for linux and on...
But for example, if I'm compiling program for Windows written in native c++ I can run it on a freshly installed windows pc? I mean, without downloading visual c++ runtime libraries, etc, I can just compile it, let's say, reinstall windows on my computer, and run it without installing anything else?
(The question above using Windows as an example but the same thing can be done on freshly installed linux distro? e.g Ubuntu)
Thanks in advance.
The only answer is "it depends".
There are many ways that an OS can "run" a program, many ways a program can be build, and many way code can be assembled.
A program that uses only "standard libraries" and that links all libraries statically, does not need any other dependency (in the sense that all the code it need is in the binary itself or into OS libraries that -being part of the system itself- are already on the system).
But:
statically link the standard libraries (which are most likely present in all programs) will bloat the memory usage of many copy of the same code. That's the reason library are often linked dynamically, but this requires "installation" of those libraries as well
Programs that use only standard libraries can do only the things that are somehow "common" (or can be commonly represented) into all systems, thus loosing all the peculiarity that makes an OS different from another.
There are "platforms" that - by the nature of their peripherals - are not represented one into the other: a coffee machine has 12 keys and a textual 2 row x 20 col display. A PC has a mouse, a keyboard, and a display that can reach even 10'000 pixel of width, of millions of color each. A tablet has a touch surface that can seize multiple points at the same time.
Can you imagine a program running the same on all those three platform?
No. Often the libraries are different on different systems. If your program involves any GUI then you will definatly have OS specific code that won't run on other OSs.
If you write a C++ program targeting the g++ compiler without GUI code there may still be some OS specific code. But you should be able to port it with minimal effort.
If your program only uses stl and stdio, then it will probably be portable. For example, MS STL's ::c_str() function works a little different than the linux one.
For what it's worth, when using MinGW with static linkage to libc and libc++, It's very likely that your C++ application will work on any Windows system '95 and later, unless you specifically enabled functionality in the Windows API that isn't available, like NT features. All of my SDL applications compiled for Windows 7 (compiled in 32 bit of course) work fine on my '95 machine.
When deploying a Linux application, it's best to just supply the source plus a configure script or makefile. This will ensure that the user has valid dependencies for your application. You could deploy binaries to specific package managers if you wanted to though.
Yes, the standard libraries are everywhere. Just think about it, most of your programs that you get are writen in C/C++. Only dependencies come when you use some specified libraries like winsock etc, therefore some windows applications are unlikely to work on linux and vice versa.
I'm new in programming. From what i know, a program that is compiled in Linux should not be able to run in Windows. So, if we want to run the same program in both platform, we need to compile the source code under both platform, and create 2 different executable files.
Recently I am studying the source code of an open source, cross-platform Java GUI application. I'm surprised to find that the backend engine of that GUI application is a small executable file generated from C++ codes. No matter users use that application in Windows or Linux, the Java GUI will call the same executable file in the bin folder.
I just want to know, how can that executable file run on both Windows and Linux?
I'm also interested to create a cross-platform Java GUI application using a C++ program as the engine. That C++ program is only available for Linux only. I've been googling for a while and i found that I need to use Cygwin to port it to Windows. However, if i use Cygwin, i will end up having 2 different executable files.
How can i combine the Windows executable file with the Linux executable file? Is it possible to generate a single executable file that can run on both platform?
Thanks.
Ok, kids.
Yes, you CAN write a multi-platform binary, but it's difficult. It's called a Fat Binary, and it used to common enough in the 1980's although I haven't seen it done in decades. https://en.wikipedia.org/wiki/Fat_binary
Basically, you compile the machine code for each platform you want to run on and then hand-link the code with different entry points. While the Wikipedia article merely describes packing different architectures into the same binary, its actually possible to make one binary that runs on different operating systems so long as the entry points for the operating systems don't collide.
Some executable formats were intentionally designed to allow this. For example, MZ, NE, LX and PE can be overlaid. Old OS/2 programs sometimes did this... they rarely contained an entire program for both operating systems, but when run on DOS would print a message telling you that you were using the wrong operating system for the program.
As far as Linux and Windows in one binary: While you can't do an ELF and PE, I believe it might be doable with a PIE or a COFF and a PE or COM. Older Linux will run COFF binaries, which PE is descended from, so it seems you might be able to create a universal binary if newer versions of Linux will still run these. I can't say for sure this would work, but it seems plausible.
Another caveat: Usually you need to put a jump in the code right at the beginning to skip past the other operating system's entry point, headers, etc. because you can't locate your code there (obviously).
The problem with this in modern computing is that most anti-virus software will incorrectly identify this as a virus. It used to be common that viruses would attack binaries by inserting such a jump at the beginning of an executable that jumped to the end of the binary, tacking their own code onto the end of the binary, then inserting another jump back to the main executable code. Since you need to do something more-or-less similar to support multiple platforms in one binary, most AV software will heuristically identify this as a virus and quarantine your executable.
So in short: YES it can be done for (some) combinations of platforms. It is not impossible, but you would have to be insane to do it.
The simple answer is, is that you can't.
The PE (Windows) and ELF (Linux) binary executable formats are totally different.
Not to mention that a C/C++ Program requires linking to libraries that won't be available on either platform simultaneously.
However, you could use Wine on Linux to run the Windows executable providing it doesn't attempt exotic Windows specific calls.
Or you could choose to use a more "common" cross-platform language such as a CLI language (C#/IronPython/Java etc.) that .NET for Windows and Mono for linux/others supports.
There is no way to have a single native executable compiled from C++ source that works on different platforms. I don't believe you that the same executable file is run on Windows and Linux, as you state in your second paragraph.
Simply put, it is not possible to run the same executable on different platforms. It is true for Windows, Linux, or any other UNIX platform.
The idea of having a single executable is nothing new and is the idea behind Java Runtime and Windows .Net (Mono for Linux). These themselves rely on different executables compiled on the specific machines.
No matter users use that application in Windows or Linux, the Java GUI
will call the same executable file in the bin folder.
They might simply be using relavant paths to these executables, and these executables are probably compiled separately on different platforms. Hard to tell without looking at the code.
Cygwin is a command line interface on windows that provides UNIX look and feel.
One option to try would be Wine which is a program for Linux to run windows programs on Linux.
It may be possible, if the OSes are on the same platform.
However, Linux can run on a variety of platforms with different processors: VAX, MAC, PC, Sun, etc.
One problem is that an executable contains assembly (machine code) instructions specific to a processor. The machine code for adding a register using ARM processor may be different than a Motorola, Intel or Sun processor. So with this context, one executable may not be guaranteed to run on different platforms.
Another issue is that the Run-Time library may also make calls to specific OS functions (like file open, displaying text, etc.) Some operating systems may not supply the same functionality; while others have a different method to execute the same functionality. An OS on an embedded platform may not support a file system. Windows Vista may block calls from unsecure MSDOS requests.
Other languages become platform independent by generating code which is executed by a "virtual machine". The code is not directly executed by a processor.
The traditional method for porting C and C++ methods is to provide the source and let the customers build the software on their platform. Other delivery processes is to create an executable for every supported platform; this becomes a maintenance nightmare.
You can't do that....i.e. you can't run the same executable on both Unix as well as Windows.
Windows uses executable files, while Unix used elf file format. They are basically different. Unlike the counterpart Java where you can run the same executable( bytecode) on both machines, which in turn uses an interpreter(the JVM) to execute.
Now, said that you have two options...
Either you can actually install C compilers on both windows and linux(unix) and then compile your code on both of them.
Or you can install 'Wine', a porting software on linux which will be able to actually run windows executable file on linux by windows emulation.
Probably, option no 2 would be better suited...Its your call...
Regards,
Can't you make a C++ program load it's respective existing libraries using #ifdef?
I think that's the C++ solution to cross platform binaries. However the code needs to be adjusted to work with both or all chosen libraries.
However without a java front end or a 2 different binaries or a bat and a sh or a program like wine you won't be able to run the respective binary.
If you create a well behaved MS Windows application, it can run unmodified on Linux x86 platforms using the wine utility.
Wine is a compatibility layer which provides Win32 and associated runtime library calls so that the program thinks it is running on MS Windows, but the wine layer translates those into Linuxisms with really good performance.
More detail at http://www.winehq.org/
I want to compile a bunch of C++ files into raw machine code and the run it with a platform-dependent starter written in C. Something like
fread(buffer, 1, len, file);
a=((*int(*)(int))buffer)(b);
How can I tell g++ to output raw code?
Will function calls work? How can I make it work?
I think the calling conventions of Linux and Windows differ. Is this a problem? How can I solve it?
EDIT: I know that PE and ELF prevent the DIRECT starting of the executable. But that's what I have the starter for.
There is one (relatively) simple way of achieving some of this, and that's called "position independent code". See your compiler documentation for this.
Meaning you can compile some sources into a binary which will execute no matter where in the address space you place it. If you have such a piece of x86 binary code in a file and mmap() it (or the Windows equivalent) it is possible to invoke it from both Linux and Windows.
Limitations already mentioned are of course still present - namely, the binary code must restrict itself to using a calling convention that's identical on both platforms / can be represented on both platforms (for 32bit x86, that'd be passing args on the stack and returning values in EAX), and of course the code must be fully self-contained - no DLL function calls as resolving these is system dependent, no system calls either.
I.e.:
You need position-independent code
You must create self-contained code without any external dependencies
You must extract the machine code from the object file.
Then mmap() that file, initialize a function pointer, and (*myblob)(someArgs) may do.
If you're using gcc, the -ffreestanding -nostdinc -fPIC options should give you most of what you want regarding the first two, then use objdump to extract the binary blob from the ELF object file afterwards.
Theoretically, some of this is achievable. However there are so many gotchas along the way that it's not really a practical solution for anything.
System call formats are totally incompatible
DEP will prevent data executing as code
Memory layouts are different
You need to effectively dynamically 'relink' the code before you can run it.
.. and so forth...
The same executable cannot be run on both Windows and Linux.
You write your code platform independently (STL, Boost & Qt can help with this), then compile in G++ on Linux to output a linux-binary, and similarly on a compiler on the windows platform.
EDIT: Also, perhaps these two posts might help you:
One
Two
Why don't you take a look at wine? It's for using windows executables on Linux. Another solution for that is using Java or .NET bytecode.
You can run .NET executables on Linux (requires mono runtime)
Also have a look at Agner's objconv (disassembling, converting PE executable to ELF etc.)
http://www.agner.org/optimize/#objconv
Someone actually figured this out. It’s called αcτµαlly pδrταblε εxεcµταblε (APE) and you use the Cosmopolitan C library. The gist is that there’s a way to cause Windows PE executable headers to be ignored and treated as a shell script. Same goes for MacOS allowing you to define a single executable. Additionally, they also figured out how to smuggle ZIP into it so that it can incrementally compress the various sections of the file / decompress on run.
https://justine.lol/ape.html
https://github.com/jart/cosmopolitan
Example of a single identical Lua binary running on Linux and Windows:
https://ahgamut.github.io/2021/02/27/ape-cosmo/
Doing such a thing would be rather complicated. It isn't just a matter of the cpu commands being issued, the compiler has dependencies on many libraries that will be linked into the code. Those libraries will have to match at run-time or it won't work.
For example, the STL library is a series of templates and library functions. The compiler will inline some constructs and call the library for others. It'd have to be the exact same library to work.
Now, in theory you could avoid using any library and just write in fundamentals, but even there the compiler may make assumptions about how they work, what type of data alignment is involved, calling convention, etc.
Don't get me wrong, it can work. Look at the WINE project and other native drivers from windows being used on Linux. I'm just saying it isn't something you can quickly and easily do.
Far better would be to recompile on each platform.
That is achievable only if you have WINE available on your Linux system. Otherwise, the difference in the executable file format will prevent you from running Windows code on Linux.
I have a program that I am sharing with a third party. I will be providing a bin executable to them. It is written in c++ but uses some c as well. they are suggesting that it needs to be c only. Do you guys think this will be a problem since I will be compiling and building it on a sparc station that will somewhat match their system specs like solaris 9 and the chipset (32 or 64) depending on what they use?
is solaris 9 able to compile the c++ code that i used or do they need to add c++ runtime libraries on their end. I am using c++ std classes. in any event if i am building it all on my end why worry about what they have? its not a static/dynamic lib that i am sharing where i think that would come into play.
just curious since they are saying it needs to be a c compilation. I suspect if they are expecting a lib then perhaps I need to address that but if its just a executable then the system specs like os and chipset is all that matters?
if i am wrong in this assumption please let know where.
Worst case you can always statically link in the C++ runtime library.
If you are only sending them an executable, I don't see why the language makes any difference whatsoever. If you're also sharing code, of course, that's an entirely different story.
Since you're providing them with only an executable (no shared libraries), you shouldn't have too much trouble.
Just run a ldd command on your binary and see which C++ libraries it links against (you might see libstdc++ for instance, if you use g++); you should include those along with your executable. Don't rely on the user having them, they might be missing or might be incompatible. You will want to use the -rpath (linker switch) to make sure your binary will use the libraries you provide and not any library found in the system.
Also, it's better to compile on an older Solaris to provide compatibility, i.e. don't compile on Solaris 10 for Solaris 7, but on 7 for 10. You get the ideea...