Idk about Bazel, but Buck2 (and Buck1, but 2 is better in every way) does handle adding -fPIC for shared libraries and leaving it off when statically linking. Each library has a PIC and non-PIC version, and the appropriate one is selected depending on if the library is being linked into an executable or a shared library. (The versions are only built when needed.) I don't remember if it also handles -fPIE similarly smartly though if you do want position-independent executables.
The Drúedain and the Dúnedain are distinct :) The Drúedain are the Púkel-men of the forest who help the Rohirrim navigate through the forest on their ride to Gondor and thereby bypass the troops that the Witch King had placed on the road to intercept them.
https://reviews.llvm.org/D69294 is an interesting case we ran into with LLD (the LLVM linker), where the the memory pressure from mmap'ing a large output file combined with filesystem compression resulted in particularly bad performance.
Limited in what way? LLVM LTO works seamlessly if you use LLD on both macOS and Windows; that's what Chrome does, for example. LLVM LTO also works pretty seamlessly with ld64 on macOS; the linker needs libLTO, but the driver takes care of that for you.
Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.
If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time.
Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one.
However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the company really committed to supporting open source projects. At that time it was more ‘if an individual engineer wanted to then go for it’ rather than there being any formal process or consideration of longer term commitments.
That changed fairly shortly afterwards with the creation of the OSS team.
I remember someone transitioning to the newly formed team and moving from Dublin to London to do so in ~2012, as we became housemates :)
Although if Evan had access to the codebase after he was an employee and if it was the Facebook codebase that was open sourced then Facebook were involved. The original post sounded (to me) like the OSS code wasn’t the same as the FB code.
I think that just backs up my point that it was the Wild West back then in terms of individual decision making.
> Additionally, it is doubtful that the new backend will allow for seamless cross-compilation to macOS since every macOS binary is required to be a PIE and link dynamically against libSystem dylib, which will require the lib's presence on the host for the lld to reference and link against.
This is true, but it's a platform requirement, not a linker requirement. How does zig's linker get around this? Does it produce static binaries (LC_UNIXTHREAD instead of LC_MAIN)?
Hey smeenai! I am the author of the MachO linker in Zig. First of, I am closely following your work in LLVM and I am really delighted that someone of your aptitude took over the backend - I definitely intend to take it for a spin soon!
As far as cross-linking is concerned, we do the same thing we do for macOS libc headers - we ship the definitions. You can think of it as effectively shipping a preprocessed version of libSystem.tbd with Zig. This is still early days though, so currently as a workaround for not having a functional yaml parser (so that `zig ld` can link against tbds), every unresolved proxy symbol is simply assumed to come from libSystem. This is of course not ideal since then unresolved symbols are flagged only at runtime rather than at link time.
Anyhow, shipping preprocessed libSystem.tbd makes it possible to cross-compile valid PIE binaries (which is a strict requirement on Apple Silicon anyway).
If you wanna discuss it more, feel free to DM me in Zig's Discord - I'm always game to discuss linkers!
