I realized that DMD is pretty close to being a cross-compiler, and won't need much work to go the rest of the way. I anticipate it could be very convenient when inconvenient to get the native DMD installed. It also should be useful for debugging problems with test suite failures :-/

Much of the static versioning in the backend is the result of converting it from C with its #if statements. Being done with all that preprocessor legacy will be nice.

Working on a series of incremental PRs to make this happen.

On Wednesday, 11 November 2020 at 10:49:54 UTC, Walter Bright wrote:
> I realized that DMD is pretty close to being a cross-compiler, and won't need much work to go the rest of the way. I anticipate it could be very convenient when inconvenient to get the native DMD installed. It also should be useful for debugging problems with test suite failures :-/
>
> Much of the static versioning in the backend is the result of converting it from C with its #if statements. Being done with all that preprocessor legacy will be nice.
>
> Working on a series of incremental PRs to make this happen.

Jonathon raised today that FreeBSD 11 -> FreeBSD 12 as been an issue for cross-compiling since the build scripts were replaced by a build.d source file.

It seems that cross-compiling between incompatible versions of libc on the same platform still needs to be sorted out.

On Wednesday, 11 November 2020 at 10:49:54 UTC, Walter Bright wrote:
> I realized that DMD is pretty close to being a cross-compiler, and won't need much work to go the rest of the way. I anticipate it could be very convenient when inconvenient to get the native DMD installed. It also should be useful for debugging problems with test suite failures :-/
>
> Much of the static versioning in the backend is the result of converting it from C with its #if statements. Being done with all that preprocessor legacy will be nice.
>
> Working on a series of incremental PRs to make this happen.

Wow nice! But will it work out-of-the-box? I mean: what about linking with druntime, for example?

Andrea

On Wednesday, 11 November 2020 at 10:49:54 UTC, Walter Bright wrote:
> I realized that DMD is pretty close to being a cross-compiler, and won't need much work to go the rest of the way. I anticipate it could be very convenient when inconvenient to get the native DMD installed. It also should be useful for debugging problems with test suite failures :-/
>
> Much of the static versioning in the backend is the result of converting it from C with its #if statements. Being done with all that preprocessor legacy will be nice.
>
> Working on a series of incremental PRs to make this happen.

But what would be a target?
ARM?
MIPS?

On Wednesday, 11 November 2020 at 16:57:53 UTC, Stefan Koch wrote:
> But what would be a target?
> ARM?
> MIPS?

Windows, Linux, and Mac I'd imagine.

I tend to just run `wine dmd` to do linux-> windows but it might still be useful anyway.

this reminds me i still need to make my generic ldc x-compile setup program.

On Wed, Nov 11, 2020 at 05:11:51PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Wednesday, 11 November 2020 at 16:57:53 UTC, Stefan Koch wrote:
> > But what would be a target?
> > ARM?
> > MIPS?
> 
> Windows, Linux, and Mac I'd imagine.
> 
> I tend to just run `wine dmd` to do linux-> windows but it might still be useful anyway.

I prefer LDC for cross-compiling, as it can do both Windows and Android cross-compile.


> this reminds me i still need to make my generic ldc x-compile setup program.

I just download and unpack both the Linux and Windows versions of LDC, then add this to ldc2.conf (for Linux version):

	"(i686|x86_64)-.*-windows.msvc":
	{
	    switches = [
		"-defaultlib=phobos2-ldc,druntime-ldc",
		"-link-defaultlib-shared=false",
	    ];
	    lib-dirs = [
		"/path/to/ldc2-1.24.0-windows-x64/lib",
	    ];
	};

Then just compile with `-mtriple=x84_64-windows-msvc` and it Just
Works(tm).  It's been awesome.


T

-- 
VI = Visual Irritation

On 11 Nov 2020 at 11:49:54 CET, "Walter Bright" <newshound2@digitalmars.com> wrote:

> I realized that DMD is pretty close to being a cross-compiler, and won't need
> 
> much work to go the rest of the way. I anticipate it could be very convenient
> 
> when inconvenient to get the native DMD installed.

Digging into Go since some weeks, and the x-compiling of it is just super:

GOOS=windows GOARCH=amd64 go build

And you get a Windows EXE from OSX. That's it, zero config setup. The simpler these things work, the better for the whole language.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Wednesday, 11 November 2020 at 21:09:14 UTC, Robert M. Münch wrote:

> Digging into Go since some weeks, and the x-compiling of it is just super:
>
> GOOS=windows GOARCH=amd64 go build
>
> And you get a Windows EXE from OSX. That's it, zero config setup. The simpler these things work, the better for the whole language.

The reason why it works for Go is because they have their own full toolchain. That means, their own compiler (including backend), their own assembler, their own object format and their own linker. All of these are written to be cross-target. In addition to that, Go only interfaces with the kernel API. On Linux, that means direct system calls, they're not even going through the C wrappers. That's perfect for cross-compiling, since there's nothing to link against.

They used to do this on macOS as well, but had to back down, because on macOS the ABI is not the kernel, but the C wrappers for the system calls.

Zig is doing something similar, they're actually doing one better. Zig supports cross-compiling of C and C++ code as well (I don't think Go does this). Zig ships with Clang and the C standard library for various targets. But Zig uses their own frontend but the LLVM backend and the LLD linker. They do seem to have some trouble with linking some things on macOS. Also, on macOS they're cheating. Because they cannot ship the SDK, they solve the linking problem by allowing undefined symbols. I don't know if Go does the same.

Unfortunately it won't be that simple for D. D took the easy way out and relies both on the C standard library and other platform specific libraries implemented in C. While it's easy to cross-compile and object file, linking will not be as easy. There's LLD, which works on Windows and Linux, but it doesn't work for macOS. You also need the SDK to have something to link with. Targeting Windows, it might be this easy, using LDC, because it's already relying on LLD and the MinGW libraries.

--
/Jacob Carlborg

On Wednesday, 11 November 2020 at 12:28:17 UTC, Iain Buclaw wrote:

> Jonathon raised today that FreeBSD 11 -> FreeBSD 12 as been an issue for cross-compiling since the build scripts were replaced by a build.d source file.

What's the issue with that? Use LDC and compile build.d to target FreeBSD 12. Sure, you need the SDK, but you should be able to copy that from a FreeBSD 12 machine.

--
/Jacob Carlborg

On Thursday, 12 November 2020 at 06:45:37 UTC, Jacob Carlborg wrote:
> On Wednesday, 11 November 2020 at 12:28:17 UTC, Iain Buclaw wrote:
>
>> Jonathon raised today that FreeBSD 11 -> FreeBSD 12 as been an issue for cross-compiling since the build scripts were replaced by a build.d source file.
>
> What's the issue with that? Use LDC and compile build.d to target FreeBSD 12. Sure, you need the SDK, but you should be able to copy that from a FreeBSD 12 machine.

Judging from the state of druntime, LDC doesn't work on FreeBSD at all.

https://github.com/ldc-developers/druntime/blob/412467a452e2d12f561a2eace933dd44014af3c6/src/core/sys/freebsd/sys/mount.d#L291-L302

What's broken? pragma(mangle) string is invalid.
What needs to be fixed? There needs to be a new pragma(symver) added to support symbol versioning feature of ELF.

---

If it was me porting, I'd do it in the stages of:
1. Build FBSD11 compiler on FBSD11.
2. Cross-compile FBSD12 compiler on FBSD11 using compiler built in stage 1.
3. Copy FBSD12 compiler over to FBSD12.
4. Build FBSD12 compiler on FBSD12 using compiler built in stage 2.

I think where Jonathon is going wrong is in skipping step 2 and jumping straight to three.  In the old make build system this just worked because (as I understand) there's a FBSD11 compatibility layer, allowing old binaries to run on the new system.  But as that is no more, building build.d using the stage 1 compiler on FBSD12 will result in a broken application (as it's linking against FBSD12 libc).