What stops DMD from cross-compiling?

[Rel]

On Friday, 27 April 2018 at 15:31:37 UTC, Jacob Carlborg wrote:
> DMD can cross-compile between 32-bit and 64-bit on the same 
> platform. To targeting a different platform than the host the 
> code in DMD needs to be reorganized a bit. When compiling the 
> compiler it will only include support for targeting the same 
> platform as you're compiling on. Currently it's using #ifdefs 
> to decide which target should be supported. This occurs the 
> compile time of the compiler. This needs to occur at runtime 
> instead. It doesn't depend on anything expect for the standard 
> C library so it should be fairly straight forward to fix.

Well, that's a good news.

> That would work, but it requires a lot of effort. It's not only 
> depending on the C standard library, it also depends on other 
> system functionality that are not part of the kernel. For 
> example, the thread local storage implementation depends on the 
> platform. If we're only using the kernel that would be needed 
> to be implemented as well.

Something like memcpy and similar stuff is easy to implement.
If we are talking about Linux stuff like open, malloc and etc
can be implemented either by using syscalls or by generating
the binding to the libc.so of some minimal version that we
decide to support (like Pascal compiler do). If we are talking
about Windows all of the needed functions can be reimplemented
using API provided by kernel32.dll and friends.

> It's possible to use the libraries provided by the target 
> platform when cross-compiling. I've done that with LDC and 
> created two Dockerfiles, one targeting Windows [1] and one 
> targeting macOS [2]. Note, the SDKs for macOS and Windows are 
> downloaded from Dropbox accounts.

Downloading some SDK's from dropbox accounts is the thing I'd
like to avoid, I'd like the Dlang compiler to be a self-contained
toolchain. This doesn't mean something, just a personal 
preference.