Linux -> Windows crosscompiler

Tue May 16 00:16:37 PDT 2017

Hi,

On Mon, May 15, 2017 at 05:58:22PM +0000, kinke via digitalmars-d-ldc wrote:
> It should indeed be possible today. For LDC, MinGW was once supported but
> isn't anymore [although fixing that shouldn't be that hard]. We chose to
> focus on the 'native' path on Windows, centered around Microsoft's Visual
> C++ (its C runtime and its toolchain). So if you are fine with that,

Well, "fine" does not exactly fit it. I am impressed by the pure size of
the installation as such. It took over three hours to install MSVC
(kinda slow hard drive) on my Windows 7 system, and it now crashes on
startup with a COM exception whenever I open an SLN file. And all I want
is just a compiler+linker...

> all you basically need is
> 
> a) an MS-compatible cross-linker (LLVM's lld),

That looks doable.

> b) druntime and Phobos compiled for Windows (you could just copy them from a
> Windows release package),

Okay. Ideally, of course, they could be crosscompiled as well.

> and
> c) a bunch of MS libs (WinSDK + Visual C++ ones)

Is there a list which libraries are required? Is it just those listed
when I run LDC with the "-v" switch?

> while specifying something like `-mtriple=x86_64-pc-windows-msvc` in the LDC
> command line.

I tried, and it correctly output an .obj file that file(1) classifies as
a COFF library file. Naturally, it does not do linking, most likely to
the problem you described here:

> There's one catch though: you currently cannot specify an alternative
> external linker to be used for MSVC targets (`link.exe` is hardcoded),

The command silently fails, i.e., it does not even print an error
message:

    % ldc2 -mtriple=i686-pc-windows-msvc hello.d
    % echo $?
    255

At least a short note that link(.exe) could not be found would be
appropriate I think.

As mentioned, the compilation as such appears to be successful and
results in an obj file to be created:

    % ls -hl
    insgesamt 16K
    -rw-r--r-- 1 user users   73 16. Mai 08:50 hello.d
    -rw-r--r-- 1 user users 8,4K 16. Mai 08:51 hello.obj
    % file hello.obj
    hello.obj: Intel 80386 COFF object file, not stripped, 29 sections,
    symbol offset=0x1124, 111 symbols

(hello.d is a simple hello world programme in D)

> so you'd have to link manually or hack the LDC source. Generating
> static libs only is supported for any target starting with LDC 1.3.

For reference, I used this ldc for my tests:

    % ldc2 -version
    LDC - the LLVM D compiler (1.2.0):
      based on DMD v2.072.2 and LLVM 3.9.1
      built with DMD64 D Compiler v2.072.2
      Default target: x86_64-pc-linux-gnu
      Host CPU: ivybridge
      http://dlang.org - http://wiki.dlang.org/LDC

      Registered Targets:
        amdgcn  - AMD GCN GPUs
        bpf     - BPF (host endian)
        bpfeb   - BPF (big endian)
        bpfel   - BPF (little endian)
        nvptx   - NVIDIA PTX 32-bit
        nvptx64 - NVIDIA PTX 64-bit
        r600    - AMD GPUs HD2XXX-HD6XXX
        x86     - 32-bit X86: Pentium-Pro and above
        x86-64  - 64-bit X86: EM64T and AMD64

> Oh and lld isn't able to produce .pdb debuginfos at the moment. The plan is
> to integrate lld in LDC at some point, see
> https://github.com/ldc-developers/ldc/issues/2028.

Will the integration of lld remove the dependency on MSVC's link.exe? In
that case, crosscompilation to Windows would probably be easier.

Thank you both for your suggestions. I may fiddle with the topic further
by investigating lld, but if it is about to be integrated into LDC
anyway, I may also just wait for that to happen. I however realised that
there is an additional problem; I would have to crosscompile my C
dependencies as well, targetting MSVC. That is not possible as of now to
my knowledge. One can crosscompile targetting MinGW (MXE does a great
job here), but not targetting MSVC. Even if it would be, I bet that
people's build systems do not cover that case and thereby cause a lot of
work on each dependant project's build system for me, which I don't have
the time for.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F