On Friday, 22 December 2017 at 09:46:40 UTC, Jacob Carlborg wrote:
On 2017-12-22 00:11, Atila Neves wrote:
I tried lld on Linux for D binaries and some of them crash.
That might not mean anything on Windows, but given that I've
run into 2 dmd bugs so far in which picking one of ld.bfd or
On 2017-12-22 00:11, Atila Neves wrote:
I tried lld on Linux for D binaries and some of them crash. That might
not mean anything on Windows, but given that I've run into 2 dmd bugs so
far in which picking one of ld.bfd or ld.gold produced crashing
binaries, I'd be wary of using lld on Windows
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei
Alexandrescu wrote:
I only became aware today about https://lld.llvm.org, llvm's
own linker. I wonder how that changes distribution dynamics for
us - I heard ldc already uses its embedded variant for linking
programs (on Widows? Posix?
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking
programs (on Widows? Posix? 32bit? 64bit?).
Currently only for Windows-MSVC targets (both 32 and 64 bits) and
only when specifying the `-link-internally` switch.
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking
programs (on Widows? Posix? 32bit? 64bit?)
Internal linking is currently enabled by a separate command-line
flag; we still use the system linker by default (just
I only became aware today about https://lld.llvm.org, llvm's own linker.
I wonder how that changes distribution dynamics for us - I heard ldc
already uses its embedded variant for linking programs (on Widows?
Posix? 32bit? 64bit?). Can we distribute it as an alternative to
optlink? Thanks! --
