Compile for Ubuntu on Windows

[Baker]

Is there a way to compile for, say, Ubuntu Linux using a Windows machine ...

a) With Cygwin
b) Without Cygwin

I recall reading up on this a year ago and it sounded like a major pain. And I've never attempted to do it.

But in earlier times, I compiled PSP Quake on a Windows machine and I compile C for Android on a Windows machine.

[frag.machine]

VirtualBox ? Yeah, it will be considerably slower, but is far less hassle than setting up a Windows environment.

[Baker]

I meant doing it for real. Not with a virtual environment.

[frag.machine]

In this case you may want to check the new Linux subsystem in Windows 10, a legacy from the abandoned Android support. You can run a number of native CLI Linux development tools directly under Windows, and IIRC gcc is one of them.

[Spike]

something like: http://metamod-p.sourceforge.net/cross- ... linux.html (that looks like an old page, but you can probably use the linked tools to compile your own more recent version)
gcc has pretty good docs for setting up a cross-compilers, but setting up the build-sysroot can be more awkward.

the win10 support for linux binaries should be simpler, but iiuc a) it is currently beta versions of win10 only, b) has poor integration so it might be hard to automate things, c) requires you to accept the win10 eula.

[revelator]

It was not abandoned its just rolled into vs2015 using clang now.
But yeah the new subsystem seems interresting, i also heard mentioned that there is ongoing work on a full ubuntu port to run on windows subsystem.

[frag.machine]

@revelator: You're right, I worded it poorly. What was discontinued was , which aimed to run Android applications binaries natively on Windows. Android as a target platform for development remains supported.

[Baker]

Thanks for the replies.

I'll need to digest some of these a bit, I've been indisposed for a couple of days.

@spike, I've come across that page before. The last update was 2007 which scares me just a little, especially since Linux was 32-bit back then and it is 64-bit now. But yeah, I read all of your message so I do see that little glimmer of hope.

[Baker]

A necessarily lazy question: Why does gcc often depend on a Linux environment (aka Cygwin)? It is just the command switches or is there something incredibly obvious that I'm not considering?

Or is it a more subtle thing like shell scripts?

(The question is necessarily lazy because I'm not sure I understand that dependency well enough to appropriately solve it myself even with a best effort?)

[Spike]

you need four things to compile code.
1) some source code.
2) a compiler, and a linker.
3) system headers+system libraries+other libraries.
4) a build script.

the vast majority of build scripts are either gmake-based (either directly or indirectly via some other system like cmake), or ide-based (like msvc project files, although mingw-using ides tend generate or directly use makefiles).

so because the majority of build scripts that use gcc also use gmake, and gmake directly exposes all sorts of unix commands (read: unix programs), and ./configure scripts are just bash scripts with all sorts of wild and whacky unix commands, a stand-alone gcc is actually quite hard to use.

additionally, those various libraries is most easily provided by just including an entire sysroot... and if you have one of those then you probably have all those unix commands anyway, so noone really cares about not using them for every single serious build script ever made.

fte uses/used a number of toolchains, like android, nacl, emscripten(gah!), msvc, all via cygwin's version of gmake.
cygwin paths are annoying when you've got native win32 toolchains, but hey, it can work.
an alternative would be to use mingw's msys, but I personally always just stuck with cygwin.

it is possible to use microsoft's nmake instead of course (even without one of microsoft's compilers), or just recompile everything each time from a batch file, etc, but these are limiting/annoying to use.
there's also java-based build systems too of course, and google pretty much force this on you with android (partly because you'll have java anyway, so you might as well use a java-based build system to compile your android program's java code), it sucks for portable native code, but its fine for system-specific android junk.

so yeah, you only need bash and friends to run the shell scripts that form the build system of whatever you're compiling rather than for the toolchain itself (this includes cross compiling gcc yourself, but not necessarily using the result of that).

[Baker]

[revelator]

Posix environments like cygwin/msys are mostly there to make it easier porting stuff written for use with autotools, if you take the time writing windows solutions for say codeblocks or msvc (which will end up being most of your life) you can do the job without these .

There are actually tools to simplify such a task, but for those tools to spit out solutions for msvc / codeblocks etc.
You still need the before mentioned posix environments atleast once.

Also you will run into problems on some sources since msvc is lacking some api headers which mingw/mingw-w64 use like inttypes.h and which some sources require.
If you search the net you can find most of these missing headers ported to msvc though.

[ericw]

It looks like this downloads that were previously on http://metamod-p.sourceforge.net/cross- ... linux.html are no longer available (but it would be an ancient compiler by now, anyway), and the system they were using to build the cross-compiling environment is discontinued, but superseded by: http://crosstool-ng.org/

Sounds like crosstool-ng can do what you want.. I'd install cygwin, build crosstool-ng within cygwin, configuring crosstool to build a x86_64-pc-linux-gnu toolchain (?). Assuming it works how I expect, you'd get a GCC called something like x86_64-pc-linux-gnu-gcc.exe , plus linux headers + libraries needed to compile code.

If you just want to compile Linux binaries of a project, I think installing VirtualBox and Ubuntu is the way to go.. the cross-compiling will probably be a lot more work overall. But could be fun I guess..

[Baker]

Thanks ericw. I thought files were missing too.

[revelator]

Btw. msys2 supports android as a target but im not sure ubuntu is supported yet, might be something to take up with the devs since crosstool-ng is allready a part of the msys2 package.