I'm exploring the idea of creating an LDC Windows (host) to arm-linux-gnueabihf (target) cross-compiler.  However, it appears LDC still expects GCC to be present for linking, even on Windows.

Does LDC still have a hard dependency on GCC for linking?

I suppose even without GCC, itself, LDC would still need the libraries that GCC pulls in automatically (libc, etc.).  Is there any plan to remove the dependency on the GNU toolchain altogether sometime in the future?  Does LLVM have its own implementations of libc or whatever else LDC requires from the GNU toolchain?

Thanks,
Mike

On Monday, 9 April 2018 at 01:04:51 UTC, Mike Franklin wrote:

> I suppose even without GCC, itself, LDC would still need the libraries that GCC pulls in automatically (libc, etc.).  Is there any plan to remove the dependency on the GNU toolchain altogether sometime in the future?  Does LLVM have its own implementations of libc or whatever else LDC requires from the GNU toolchain?

Well, actually, I suppose libc, libm, libpthread, and whatever else is needed to create a binary is actually provided by the target, and not by the GNU toolchain.  I suppose I could copy the necessary .a/.o/.so files to the Windows host, but is there some way to have ldc invoke lld.exe on the host, or will I have to resort to -c (separate compile and link) to avoid having to provision a windows GCC toolchain?

On Monday, 9 April 2018 at 01:04:51 UTC, Mike Franklin wrote:
> I'm exploring the idea of creating an LDC Windows (host) to arm-linux-gnueabihf (target) cross-compiler.  However, it appears LDC still expects GCC to be present for linking, even on Windows.

You can specify `-link-internally`, which at least works when not cross-compiling on Windows. There's also the `-linker` flag which allows you to specify which linker to use, but it still invokes GCC. You can use the `CC` environment variable to override the C compiler that is invoked for linking.

> Does LDC still have a hard dependency on GCC for linking?
>
> I suppose even without GCC, itself, LDC would still need the libraries that GCC pulls in automatically (libc, etc.).  Is there any plan to remove the dependency on the GNU toolchain altogether sometime in the future?  Does LLVM have its own implementations of libc or whatever else LDC requires from the GNU toolchain?

LLVM contains replacements for most of the GNU toolchain, although it does not have its own implementation of libc. musl can be used as a replacement but only on Linux.

--
/Jacob Carlborg

On Monday, 9 April 2018 at 01:45:38 UTC, Mike Franklin wrote:

> Well, actually, I suppose libc, libm, libpthread, and whatever else is needed to create a binary is actually provided by the target, and not by the GNU toolchain.  I suppose I could copy the necessary .a/.o/.so files to the Windows host, but is there some way to have ldc invoke lld.exe on the host, or will I have to resort to -c (separate compile and link) to avoid having to provision a windows GCC toolchain?

You can link with Clang instead of GCC by setting the `CC` environment variable. Clang is already a cross-compiler. Using the `-isysroot` you can specify the root directory where it tries to find libraries, includes and binaries.

--
/Jacob Carlborg

On Monday, 9 April 2018 at 06:59:43 UTC, Jacob Carlborg wrote:

> You can link with Clang instead of GCC by setting the `CC` environment variable. Clang is already a cross-compiler. Using the `-isysroot` you can specify the root directory where it tries to find libraries, includes and binaries.

You can also have a look at ELLCC [1], a cross-compiler built on Clang.

[1] http://ellcc.org

--
/Jacob Carlborg

On Monday, 9 April 2018 at 01:04:51 UTC, Mike Franklin wrote:
> I'm exploring the idea of creating an LDC Windows (host) to arm-linux-gnueabihf (target) cross-compiler.  However, it appears LDC still expects GCC to be present for linking, even on Windows.
>
> Does LDC still have a hard dependency on GCC for linking?

For non-Windows targets, we expect a gcc-compatible linker driver, i.e., gcc or clang, and as Jacob pointed out, you can choose between them via CC env variable (and a hidden -gcc option IIRC).

A while ago, I integrated LLD into LDC itself. It's currently only able to link MSVC binaries, so `-link-internally` only works for MSVC targets.
There's a PR in which I extended it to ELF and Mach-O targets too; it seems to be working after a quick test (if you have the required libs obviously), but the needed linker flags normally added by gcc makes the command-line explode: https://github.com/ldc-developers/ldc/pull/2203#issuecomment-339167131

The command-line flags could be added once to the config file though if your environment is stable.

> I suppose I could copy the necessary .a/.o/.so files to the Windows host

Yep, that's what I'd do.

Thanks Jacob and kinke for the advice.

I've been able to piece together a Frankenstein toolchain using LLVM 6, ldc2-1.8.0-windows-x64, and ldc2-1.8.0-linux-armhf

I compile using ldc2-1.8.0-windows-x64:
ldc2 -c main.d

I create a samba share on my ARM device use it as sysroot from the Windows host at \\192.168.0.26\root.

I pull the `lib` folder out of ldc2-1.8.0-linux-armhf for the following linking task.

I link with something like this (pieced together from my notes; may not be perfect):
ld.lld.exe -static -m armelf_linux_eabi -o main
-sysroot \\192.168.0.26\root
\\192.168.0.26\root\usr\lib\arm-linux-gnueabihf\crt1.o
\\192.168.0.26\root\usr\lib\arm-linux-gnueabihf\crti.o
\\192.168.0.26\root\usr\lib\arm-linux-gnueabihf\crtbegin.o
-L \\192.168.0.26\root\usr\lib\arm-linux-gnueabihf
-L \\192.168.0.26\root\usr\lib\gcc\arm-linux-gnueabihf\4.9.2
main.o
\\192.168.0.26\root\usr\lib\arm-linux-gnueabihf\crtend.o
\\192.168.0.26\root\usr\lib\arm-linux-gnueabihf\crtn.o
-L C:\ldc2-1.8.0-linux-armhf\lib -lphobos2-ldc -ldruntime-ldc
-lrt -ldl -lpthread -lm -lc -lgcc -lgcc_eh

It works.

I couldn't get linking with clang or separate dynamic linking to work; my binary ends up throwing a segmentation fault, but I suspect I could probably troubleshoot and work out what I need to do eventually.

> A while ago, I integrated LLD into LDC itself. It's currently only able to link MSVC binaries, so `-link-internally` only works for MSVC targets.
> There's a PR in which I extended it to ELF and Mach-O targets too; it seems to be working after a quick test (if you have the required libs obviously), but the needed linker flags normally added by gcc makes the command-line explode: https://github.com/ldc-developers/ldc/pull/2203#issuecomment-339167131
>
> The command-line flags could be added once to the config file though if your environment is stable.

That looks really nice.  I see you had to patch lld; is that going upstream?

How does clang know how to generate its linker command?  Whatever it is, can ldc be made do the same?

Mike

On Wednesday, 11 April 2018 at 00:39:23 UTC, Mike Franklin wrote:

> I compile using ldc2-1.8.0-windows-x64:
> ldc2 -c main.d

Oops! forgot the most important part; the triple.  It should be something like this:

ldc2 -triple=arm-linux-gnueabihf -c main.d

Mike

On Monday, 9 April 2018 at 01:45:38 UTC, Mike Franklin wrote:
> Well, actually, I suppose libc, libm, libpthread, and whatever else is needed to create a binary is actually provided by the target, and not by the GNU toolchain.  I suppose I could copy the necessary .a/.o/.so files to the Windows host, but is there some way to have ldc invoke lld.exe on the host, or will I have to resort to -c (separate compile and link) to avoid having to provision a windows GCC toolchain?

You can write a small program (in D) named "gcc", that will forward arguments to lld.

On Wednesday, 11 April 2018 at 00:39:23 UTC, Mike Franklin wrote:
> How does clang know how to generate its linker command?

I don't think it does, it's probably hard-coded based on the target, though you can usually override various elements with flags. Since every target has its own selection of flags and object files it needs, we delegate linking to the C (cross-)compiler for that target.

You can always choose your own linker for ldc with the -linker= flag and do everything manually if you want though.

> Whatever it is, can ldc be made do the same?

Yes, but it would be an impossible task to do it for any non-trivial set of platforms. It's _much_ easier to free-ride off the C compiler which has already been configured for the target.