My understanding is that the darwin flavor uses the atom-based architecture, while the gnu and windows/link flavors use a section-based architecture. There was a thread on the llvm-dev mailing list that explains this in more detail. [2]
I don't know much about the linker script side of things, but I was under the impression that they were working on that.
[1] http://lld.llvm.org/Driver.html [2] http://lists.llvm.org/pipermail/llvm-dev/2015-May/085088.htm...
You can of course use GNU ld with Clang/LLVM if you so choose; this is the default on FreeBSD/arm64 today. The new point with 3.9 is that the full Clang/LLVM + lld toolchain can self-host (using the lld ELF support). ELF lld supports a significant subset of the linker script syntax, and additional functionality is being added as actual uses are found. (It's sufficient to link the FreeBSD kernel today.)
...but not Mach-O, Apple's format.
[1] https://en.wikipedia.org/wiki/Binary_File_Descriptor_library
And if you do need to build for multiple targets, you just run the binutils tools multiple times with the right options for each, because they're never identical.
Compiling per-target toolchains is an annoying chore, and binutils is the last holdover bugging me with this when I work with Rust.
The question here is whether you can run the same tool (the same binary) for two different targets, or if you have to run a different version of e.g. ld built specifically for each target.
So I've been having some "fun" with LLVM targeting AArch64, and was rather, er, disappointed when I discovered the toolchain didn't use GNU ld, but Mach's ld64.
Now in theory, ld64 is a next-gen linker that can link code not at the "module" (one compiled C file) level, but at the individual function and (global) variable level. Cool! More granularity! Except it doesn't support anything equivalent to GNU ld's extremely useful linker scripts, the stuff that says "put this code in SRAM, that data in Flash. etc..." and its command-line is... poorly documented. Also, it only works with Mach-O binaries, which is incompatible with objdump, that swiss-army knife of object code [1].
And anyhow, what does LLVM refer to as LLD? Because there are actually two separate projects under that umbrella: The ELF/COFF one (http://lld.llvm.org/NewLLD.html) and the ATOM-based one (http://lld.llvm.org/AtomLLD.html)
As I understand, the ATOM-based linker is still experimental, so they're referring to the ELF/COFF one?
TL;DR: LLVM doesn't hold a candle to binutils
[1] I recommend trying out using objdump to turn your app data into object data you can link directly into your application. This is what modern toolchains call "resources", but it's really interesting to test it out at the C/"bare-metal" level to see how it works. Bonus: you get to really learn the difference between pointers and arrays ;)