What stops DMD from cross-compiling?

Rel relmail at rambler.ru
Fri Apr 27 10:56:50 UTC 2018


So, okey, bare with me here. As I once told here before the only 
one thing I love about Golang is the ability to easily 
cross-compile code from any supported OS targeting any supported 
OS. So I was thinking what actually stops DMD from doing the same 
thing? DMD has own backends targeting X86 and x64 already, it 
seems to work well with LLD (at least for me) that was integrated 
not so long ago, and LLD has the ability to cross-link.

So I'm not a compiler expert here, and I'm not familiar with the 
DMD code base, but from a user perspective the one huge 
showstopper for bringing the same level of cross-compilation to 
DMD like Golang has seems to be the dependency on C-library. As 
of 2.079 we can write code that is not dependent on the druntime 
and libc, so technically we can reimplement the needed parts of 
cruntime in D and make it the part of druntime itself. What do 
you think about it?

Also we will need some libraries that would generate bindings 
from extern functions to actual OS library code, like for example 
kernel32.lib on Windows. The library doesn't have actual code, it 
just binds the symbol to the executable import table. Pascal 
programming language doesn't seem to have the same notion, when 
you declare extern function you just declare it with the actual 
library name (like kernel32.dll on windows) and the compiler 
generates the proper imports. Can the behavior like this be 
implemented for DMD? How we can solve this problem otherwise?

And any other thought on the topic is welcomed, I like talking 
about compilers and stuff with some wise and experienced people. 
Thanks!


More information about the Digitalmars-d mailing list