smeenai

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.

starlark-rust (used by Buck2) supports this! They're immensely useful for grokking complex build code, as you said. https://github.com/facebook/starlark-rust/blob/main/docs/typ...

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.

Disclaimer: I work at Facebook.

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.

Not disagreeing with the rest, but LLD can link for Apple Silicon as well, and you could use Clang with zld as well if you wanted.

VS community edition is free (but not an option for commercial work).

Another Clang-specific way to handle the case insensitivity is by making use of a virtual file system (VFS) overlay. https://github.com/llvm/llvm-project/blob/4976d1fe58f89169ef... demonstrates how that works. (There's no linker equivalent that I'm aware of, so you do have to use the symlinks or something like ciopfs for that; https://github.com/llvm/llvm-project/blob/4976d1fe58f89169ef... is an example of symlink generation.)

I was curious about this bit from https://ziglang.org/download/0.8.0/release-notes.html#Self-H..., since I work on the new LLD for Mach-O backend:

> 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)?

clang-tidy has a struct padding check which diagnoses non-optimal struct orders, and a coworker contributed a clang tool to reorder fields: https://github.com/llvm-mirror/clang-tools-extra/tree/master...

LLD (the new linker from the LLVM project) actually does exactly this; by default, it creates a separate read-only segment, and you have to pass --no-rosegment explicitly if you don't want this.

Amusingly enough, I ran into some issues because of this; e.g. valgrind's symbolication was failing on LLD-linked binaries unless I used --no-rosegment. I didn't dig into it too much, but it's probably making some bad assumptions about the text section's load address. (LLD places the read-executable segment after the read-only segment, and I think valgrind was assuming that the text section would be part of the first segment.)

> In kirundi (a common language in Burundi) there is one word for both yesterday and tomorrow.

This is true in Urdu and Hindi as well.

ARM supports the stack growing in either direction, but on Windows ARM it grows down.

PE/COFF does have some architectural differences though; for example, the relocation types differ across architectures.