g++ failing to compile

[Christian-Hill-zz]

g++ fails to compile

• Every time I compile a program using g++ on WSL and try to run it in my desktop, it provides an error, on further inspection it produced 16 bit code instead of 64 bit. I've tweaked g++ to compile 64 bit specific code and I'm still getting this error.

• Expected to spit out a working .exe binary file.

• Spits out a file that cannot execute

• g++ -o example.exe example.cpp

• gcc, gcc multilib , g++

See our contributing instructions for assistance.

[therealkenc]

Multilib is your problem [edit see below] -- not supported by design. There's a user voice here. Imagine it would be mostly busy-work to add; assuming a 64-bit Windows was still a requirement. Good summer intern project. #711 is also dangling open.

[Christian-Hill-zz]

Is there a way for me to compile a binary my 64-bit windows machine can execute outside of WSL?

[therealkenc]

Okay now I follow what you did (had to double take). Disregard my last post. g++ -o example.exe on WSL is going to create a Linux ELF binary that happens to have an .exe extension (which is not well formed by convention), not a Windows PE binary; which is what you need if you want the binary to run on your Windows Desktop. [Funny thing about those names. ELF binaries aren't Extensible and PE binaries aren't Portable.]

Yes, you can create a PE binary on Linux (WSL or the real thing) by cross-compiling, but I'm going to go out on a limb and bet that's not what you're after. Download a copy of Visual Studio Community and create PE binaries on Windows for fun and profit. If you are really trying to create Windows PE binaries on Linux, you can use the mingw-w64 cross compiler package. None of this is a WSL thing, mind. Same answer would apply if you asked the question on a Linux forum.

[mateusmedeiros]

@Christian-Hill You have to understand what WSL is. It is not a simple shim layer with fake binaries that work the same as the native ones but are actually windows binaries behind the curtains. WSL runs an ACTUAL ubuntu distribution with the exact same binaries you would run on a normal ubuntu machine. When you run gcc, you're running the native linux gcc, the same you would run on an actual ubuntu distribution.

So imagine the following, you're running that command g++ -o example.exe example.cpp in a separated computer you have, which runs on a normal Ubuntu Linux distribution. If you just copied the resulting example.exe to a usb drive and then put that on your windows PC and ran it, would you expect it to work?

It wouldn't work. And that's because you compiled it on one OS and ran on another (that is not binary compatible). The same thing applies here. Inside WSL you're running an authentic Ubuntu distribution, the only difference being that at kernel level, the system calls are translated to their equivalent NT kernel system calls (though certainly the translation is not always one-to-one). To compile something on WSL that you want to run on windows, you will have to cross-compile, as @therealkenc said. Same thing you would have to do to compile something on your hypothetical separated Ubuntu PC to be able to run it afterwards on your Windows PC.

[EgZvor]

Is there a way to compile and build a project with make using mingw compiler on Windows, so that it would work on Windows afterwards?
The goal is to make a project on Windows, but it doesn't work correctly with nmake.

[aseering]

This is probably possible, but it could easily get complicated.

One way would be to simply call /path/to/gcc.exe from Linux. This might be as simple as setting the CC environment variable to /path/to/gcc.exe. I haven't tried, though. You could play around with that idea.

Another way would be to use a cross-compiler: There are builds of gcc for native Ubuntu that will produce Windows binaries. The general term for building binaries on platform A but for platform B is "cross compilation". There are lots of guides to doing this online.

Also -- if all you need is a replacement for nmake, Linux make (aka "gmake") has actually been ported to Windows:

http://gnuwin32.sourceforge.net/packages/make.htm

If all you need from Linux is its make command, that's probably the easiest solution.

[EgZvor]

@aseering Thank you for answering!
It turns out there's a lot of Unix dependent libraries like <sys/mman.h>, so I'm veering towards using a virtual machine. I did indeed try to use that gnu make, but it's not cause of all the problems.

[aseering]

@EgZvor -- no problem!

I'm curious, though -- how would a virtual machine help in this case? If it's a Windows VM, then you're still stuck with nmake. If it's a Linux VM, then you still have the problem that your UNIX dependencies won't be available when you copy your executable over to Windows in order to run it.

[EgZvor]

@aseering
I won't be using Windows to run it. It's not just an executable it's a python library with compiled components. And if I try to compile it in WSL it says
don't know how to compile C/C++ code on platform 'nt' with compiler 'gcc'
because I'm using python from Windows.
So I guess I could just use python in WSL, but I'm not sure if I could then do computationally expensive stuff. Thanks for bringing me on track.

[aseering]

@EgZvor -- yeah, I would just use Python in WSL. It's just a Python process, running natively on your processor; it should handle CPU-intensive stuff at least as well as a VM. Maybe better in some cases.

There are limitations for other types of performance. For example, WSL doesn't expose graphics cards to Linux applications, so you can't do GPU-accelerated computation. Also, disk operations can be slower than in a VM, depending on what you're doing. But simple CPU-intensive workloads should be fast and should work well.

[therealkenc]

The OP here ended up being a question about g++ usage.