What stops DMD from cross-compiling?

[Jacob Carlborg]

On 2018-04-28 10:49, Rel wrote:

> 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.

For macOS I'm thinking functions that are implemented in the dynamic 
loader [1] or other platform specific functions [2]. For macOS the 
thread local implementation is in the dynamic loader. It will setup TLS 
variables before C main function is called. That would need to be 
reimplemented.

> Downloading some SDK's from dropbox accounts is the thing I'd
> like to avoid, 

If you have access to a machine running the target system you can 
copy/extract the SDK yourself. If you don't have there's Travis CI which 
has support for macOS and AppVeyor which supports Windows which you can 
copy the SDK from.

When it comes to the SDK for macOS we might be able to ship our own SDK. 
Most of the libraries are dynamic libraries. The SDK doesn't actually 
contain any real libraries, only YAML files containing some metadata and 
the symbols the library defines. We could generate those YAML files 
ourselves based on the real libraries.

I don't know what the SDK EULA says about this. But since we created the 
files I think we should be able to distribute them.

> I'd like the Dlang compiler to be a self-contained
> toolchain.
That would be ideal yes.

[1] 
https://github.com/dlang/druntime/blob/master/src/core/sys/darwin/mach/dyld.d

[2] 
https://github.com/dlang/druntime/blob/master/src/core/sys/darwin/mach/getsect.d

-- 
/Jacob Carlborg