ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Why would anyone ever want to do this? I don't know. But is there anyway to compile a C++ program in linux, but compile it as a Windows .EXE? Personally, I don't need to do this, but if it exists, I'd like to know about it.
Location: Location??? Where I am is top secret, if I tell you, I have to kill you.
Distribution: College, Slack
Posts: 24
Rep:
I am pretty sure there is no way to do that simply because, the binaries on windows an Unix/Linux are different. Try compiling a program on linux, it won't work, if you take it over to a windows box. Which is why when you go to a site and download something, it has different binaries for windows, and linux.
Originally posted by onnyloh maybe this can be achieve using wine?
Yes i know like that too.. Also there are examples like Kylix (it's a Linux port of Delphi cross-compiled with wine).
You can port a winblows program to Linux by compiling it's source code but you cannot build winblows executables on Linux. As you know there are no library required by a winblows executables in Linux. If you would use SetTimer(), where can you get the internal source of this function.. May be there are hobby projects for this purpose but i think it would be waste of time.
You _CAN_ build windows executables on linux. You _DO NOT_ need the DLLs in order to link the libraries, you only need the header files and .LIB files (which actually only contain bare requirements for importing functions, i.e. you can easily build them using implib or something like that). The reason is that EXEs have a section stating a list of DLLs including the function names.
I am oversimplifying the description now, see Windows PE format description and COFF format description. Also, see link I posted earlier in this thread.
Originally posted by max_sipos You _CAN_ build windows executables on linux. You _DO NOT_ need the DLLs in order to link the libraries, you only need the header files and .LIB files (which actually only contain bare requirements for importing functions, i.e. you can easily build them using implib or something like that). The reason is that EXEs have a section stating a list of DLLs including the function names.
I am oversimplifying the description now, see Windows PE format description and COFF format description. Also, see link I posted earlier in this thread.
Wow.. sorry about that. What i mean was similar to that you mentioned about (we don't have included function's binaries (LIBs)) but i've not heard about the project. Additionaly, it's still waste of time according to me.. :-D
Yeah, I realize that you meant more about compiling win32 source and making it work on linux ... Yeah it's definitely a waste of time building EXE on linux, although I think some ppl use it in order to develop without having to pay for Visual Studio etc., they probably use it on native windows machines in cygwin or something of the sort. I remember that there's also the lcc compiler (implementation described in a great book about making compilers, search for lcc on amazon), and it has a port for windows lcc-win32 which is free - on the other hand, it's limited to C only.
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,789
Rep:
Technically, there is no reason not being able to build a binary for one architecture O/S from another architecture O/S. This is called cross-compiling.
There are platforms where it is the most used or even the only way to do it (developers writing programs for telephones, handheld devices, game consoles, digital cameras, ... usually do not use them as development platform )
The gnu compiler suite is built with cross compilation support, meaning that you can build binaries for a large choice of CPUs and a large choice of binary format.
Unfortunately, there are few packaged cross compilers, so you usually need to build yourself the one you need, and this is a painful experience, as it isn't the well supported area of the gnu tools.
Linux to win32 cross compilation is a common need as linux is a frequent developer's platform while windows is, whatever we like, the widely used O/S on PCs.
Unfortunately, this cross compilation using a mingw port to linux is no more maintained by its author (http://members.telering.at/jessich/mingw/) but there are certainly other efforts.
Finally, I disagree about the fact that cross-compiling is a waste of time. Actually, it can save a lot of time and money to a developer who do not need to buy the target O/S license, and boot a platform running it, but want to increase his software audience anyway.
Aside from cross-compiling, which has already been mentioned, some languages like Java, C#, etc. compile down to a standard binary format that can theoretically be used on multiple platforms without recompiling. For instance, I have compiled some C# apps with DotGNU, and run the resulting exe directly on Windows. I have also compiled C# apps in Windows using Visual Studio .Net, and had that same exe run on Linux using the DotGNU tools...
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,789
Rep:
Cross compiling was already mentioned, but I (wrongly) thought it was out of context as it only mentioned delphi.
The original question was about C++, for which there are no virtual machines like Java and C# ones, AFAIK. It's true that these languages share similarities between themselves and C++ though.
Running Java classes on multiple platforms is more than a theory, but is demonstrated since at least 8 years. One can argue that this isn't really cross-platform execution, as in fact Java and C# classes are not at all portable between platforms, but instead are only usable by a single platform which is their virtual machine.
The virtual machine is the real portable code there.
Originally posted by jlliagre Running Java classes on multiple platforms is more than a theory, but is demonstrated since at least 8 years. One can argue that this isn't really cross-platform execution, as in fact Java and C# classes are not at all portable between platforms, but instead are only usable by a single platform which is their virtual machine.
The virtual machine is the real portable code there.
When I said theoretically, I didn't mean to say that you CAN'T run it on multiple platforms. I meant that not ALL Java/C# projects will necessarily run on all platforms. For instance, if you write a Java app that relies on a Java package that only exists for Windows or Linux (The old J++ classes come to mind...), you aren't going to necesarily be able to just plop the new .class file into a different OS and be able to run it.
The same for C#... there are some classes in Visual C# .Net that haven't yet been implemented in DotGNU, so if you use those classes, you aren't going to be able to directly run the .exe on Linux.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.