Thread overview
Get DUB to skip linker and output object files?
Mar 18, 2020
Markus Pursche
Mar 18, 2020
Denis Feklushkin
Mar 18, 2020
Nicholas Wilson
Mar 18, 2020
Sönke Ludwig
Mar 18, 2020
kinke
Mar 18, 2020
Markus Pursche
Mar 18, 2020
kinke
Mar 19, 2020
Markus Pursche
Mar 19, 2020
kinke
Mar 18, 2020
kinke
March 18, 2020
Hi, we are experimenting with cross-compiling from Windows to PS4, we have figured out how to compile (using LDC with -betterC) individual .d files into object files (.o), which I can then link using the PS4 SDK into a .elf and it all runs.

I would very much like to integrate the first part of that toolchain with Dub since it would make testing different -betterC enabled libraries for ABI compatibility easier.

Here is my dub.json

https://pastebin.com/s7XexRBD

However, this is my output when running dub build -v

https://pastebin.com/TyLi5sid

My first observation is that it is still trying to link everything, is there any way I can disable this?

The second thing is that it assumes .obj and .exe files instead of .o and .elf, should I perhaps change the target platform according to DUB as well? Would that pass another triple to LDC?
March 18, 2020
On Wednesday, 18 March 2020 at 11:48:53 UTC, Markus Pursche wrote:
> Hi, we are experimenting with cross-compiling from Windows to PS4, we have figured out how to compile (using LDC with -betterC) individual .d files into object files (.o), which I can then link using the PS4 SDK into a .elf and it all runs.
>
> I would very much like to integrate the first part of that toolchain with Dub since it would make testing different -betterC enabled libraries for ABI compatibility easier.
>
> Here is my dub.json
>
> https://pastebin.com/s7XexRBD
>
> However, this is my output when running dub build -v
>
> https://pastebin.com/TyLi5sid
>
> My first observation is that it is still trying to link everything, is there any way I can disable this?
>
> The second thing is that it assumes .obj and .exe files instead of .o and .elf, should I perhaps change the target platform according to DUB as well? Would that pass another triple to LDC?

DUB is bad for cross-compilation now.

Consider a Meson instead of a DUB. there it already works.

Sample, will work for BetterC:
https://github.com/denizzzka/d_c_arm_test
March 18, 2020
On Wednesday, 18 March 2020 at 11:48:53 UTC, Markus Pursche wrote:
> Hi, we are experimenting with cross-compiling from Windows to PS4, we have figured out how to compile (using LDC with -betterC) individual .d files into object files (.o), which I can then link using the PS4 SDK into a .elf and it all runs.

I've got no idea what it will do but https://github.com/dlang/dub/pull/1900

March 18, 2020
Am 18.03.2020 um 12:48 schrieb Markus Pursche:
> Hi, we are experimenting with cross-compiling from Windows to PS4, we have figured out how to compile (using LDC with -betterC) individual .d files into object files (.o), which I can then link using the PS4 SDK into a .elf and it all runs.
> 
> I would very much like to integrate the first part of that toolchain with Dub since it would make testing different -betterC enabled libraries for ABI compatibility easier.
> 
> Here is my dub.json
> 
> https://pastebin.com/s7XexRBD
> 
> However, this is my output when running dub build -v
> 
> https://pastebin.com/TyLi5sid
> 
> My first observation is that it is still trying to link everything, is there any way I can disable this?
> 
> The second thing is that it assumes .obj and .exe files instead of .o and .elf, should I perhaps change the target platform according to DUB as well? Would that pass another triple to LDC?

There is an open PR for this: https://github.com/dlang/dub/pull/1792
March 18, 2020
On Wednesday, 18 March 2020 at 11:48:53 UTC, Markus Pursche wrote:
> [...] then link using the PS4 SDK into a .elf

Please post the command(s) you are currently issuing for linking, just to see if we really cannot get LDC to link directly / what would be missing.
March 18, 2020
On Wednesday, 18 March 2020 at 11:48:53 UTC, Markus Pursche wrote:
> My first observation is that it is still trying to link everything, is there any way I can disable this?

I guess by setting the targetType explicitly to `library`?

> The second thing is that it assumes .obj and .exe files instead of .o and .elf, should I perhaps change the target platform according to DUB as well?

That should improve when using dub's `--arch=x86_64-scei-ps4` option (which will add that as `-mtriple`, so you don't need that in the dub config). I guess dub currently detects the platform as FreeBSD and so defaults to .o for objects and no extension for binaries.
March 18, 2020
On Wednesday, 18 March 2020 at 14:52:33 UTC, kinke wrote:
> On Wednesday, 18 March 2020 at 11:48:53 UTC, Markus Pursche wrote:
>> [...] then link using the PS4 SDK into a .elf
>
> Please post the command(s) you are currently issuing for linking, just to see if we really cannot get LDC to link directly / what would be missing.

There are no special commands for the linker, the linker itself is modified and signs executables, so this will not work.
March 18, 2020
On Wednesday, 18 March 2020 at 15:28:44 UTC, Markus Pursche wrote:
> There are no special commands for the linker, the linker itself is modified and signs executables, so this will not work.

If it can be expressed in a clang cmdline, it can work.
March 19, 2020
On Wednesday, 18 March 2020 at 15:38:38 UTC, kinke wrote:
> On Wednesday, 18 March 2020 at 15:28:44 UTC, Markus Pursche wrote:
>> There are no special commands for the linker, the linker itself is modified and signs executables, so this will not work.
>
> If it can be expressed in a clang cmdline, it can work.

It is not verbose about anything it does since it's a security feature, I really don't think linking with a regular linker will do it but I can add it to my list of things to try. :P
March 19, 2020
On Thursday, 19 March 2020 at 11:21:53 UTC, Markus Pursche wrote:
> On Wednesday, 18 March 2020 at 15:38:38 UTC, kinke wrote:
>> On Wednesday, 18 March 2020 at 15:28:44 UTC, Markus Pursche wrote:
>>> There are no special commands for the linker, the linker itself is modified and signs executables, so this will not work.
>>
>> If it can be expressed in a clang cmdline, it can work.
>
> It is not verbose about anything it does since it's a security feature, I really don't think linking with a regular linker will do it but I can add it to my list of things to try. :P

Look, LDC simply invokes the C compiler for linking (for Posix targets), and that can be controlled via `-gcc`. So if Sony's clang or whatever you are invoking has a compatible command-line interface, it should trivially work. Add -v to the LDC cmdline to see the invoked linker cmdline, and -Xcc and -L to add flags to C compiler / linker.