Cannot cross-compile shared lib to x86_64-macos target on Windows host with internal linker

[MrSmith33]

ldc2
--platformlib=
-betterC
-shared
-fvisibility=hidden
-link-internally
-L-arch
-Lx86_64
-L-platform_version
-Lmacos
-L10.0
-L11.0
-mtriple=x86_64-apple-darwin
-of=D:\vbe\bin\vbe.dylib
D:\vbe\source\libvbe.d

results in

version   1.30.0 (DMD v2.100.1, LLVM 14.0.3)
...
lld D:\vbe\bin\nih.o -shared -o D:\vbe\bin\nih.dylib -arch x86_64 -platform_version macos 10.0 11.0 -LD:/Soft/ldc2/bin/../lib64 -rpath D:/Soft/ldc2/bin/../lib64 
lld: error: unknown argument '-shared'
Error: linking with LLD failed

[kinke]

Oh, wild :D - are you positive that'd be a totally standalone .dylib, not depending on any Apple lib? - The direct linker command-line interface for Posix targets (ld) isn't really tested, as it's hardly usable (=> normally linking through C (cross-)compiler instead with gcc/clang CLI). If -shared is the only blocker for the Apple ld64-compatible direct ld64.lld interface (should apparently be -dylib instead), you might get further by separating compile & link - compiling the object file(s) first, then linking via -L-dylib etc.

[MrSmith33]

It only uses a couple syscalls I think, so should be fully independent. How should the separate link step be done? Through lld-link.exe? Is it the same as internal linker?

[kinke]

I'd use LDC with -link-internally like you already did, but removing/replacing -shared and specifying the object file instead of the .d source file. lld-link.exe should be usable too, but then you need to either rename it to ld64.lld.exe before, or use something like -flavor darwin as first CLI option AFAIK.