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