How to develop for Linux x86 and arm on QtCreator on Windows?

[midix]

I'm developing a set of C and C++ applications (no GUI) for Debian Linux on x86 and arm. The project includes some old codebase with highly customized makefiles. Nothing related to Qt, Qmake or CMake. The old code works fine on Linux, I just have to extend it with some new utilities.

I'm mostly a "Windows guy" and feel much more comfortable with it. So I'd like to develop on Windows.

Is it possible and how to do it with QtCreator?

I have found various toolchains for arm and embedded (most of them are Linux based, but there are a few for Windows), but it's hard to find a toolchain to build for a generic PC machine with Debian on Windows. I guess, I'll have to try out the process described here:
http://gnutoolchains.com/building/
but I'm not sure if it will be worth the hassle - will it work at all with QtCreator?

It seems, I have two alternatives:

• cross-compiling - get some ready made QtCreator Windows build kits for generic Linux (are there any?) or define custom kits

• remote compiling - set up a share for code folder and a bunch of remote SSH commands to use in QtCreator project Build & Run settings.

It seems, both of these methods should work, but I'm not sure which one would be easier to accomplish? And, what's important - which one would still provide full QtCreator code completion and analysis (Clang or other) features?

I already tried to open one of my Linux source code projects on Windows and I see that QtCreator cannot find lots of header files which seem to be standard on Linux, therefore autocompletion and error checking does not work correctly. Where do I get those headers?

If someone has tried both approaches (cross compile and remote build) with QtCreator on Windows, I'd really appreciate your advice.

[midix]

I managed to compile binutils and GCC from Windows.

But Glibc failed:

*** The GNU C library is currently not available for this platform.

Most probably, cross-compile from Windows to Linux using Glibc is not good idea and I should use newlib instead, but I'm not sure how my project's legacy code will react to newlib. And I'll have Glibc on the final target, anyways.