3 ms·

They are talking about app-bundled dylibs, which cannot be updated separately due to the whole-bundle signing.

• notacoward 3y ago
  In other words it's a fix for a somewhat Apple-specific (and in this case Apple-created) problem?
  • astrange 3y ago
    iOS definitely isn't the only platform where apps ship their own versions of DLLs.
    • notacoward 3y ago
      No, not the only one, but the converse isn't rare either. Whether it's "bundles" or containers, a lot of people act as though bloat and slow build times because of static linking are inevitable when in fact the pain is self inflicted.
      • deleted 3y ago
        [deleted]
  • conradev 3y ago
    The problem is not Apple-specific and their solution could be useful elsewhere. The specific optimization this achieves is during build time only: these new files are static libraries that are quicker to link. It is a small shift of some of the linking pipeline into the (parallel) builds of dependent libraries, rather than heaping it all onto the linker at the end of the build. The linker has to essentially re-link from scratch for every small change. Parallelization has long been known as the best way to speed up linking. This Apple change comes in addition to rewriting their linker to be massively parallel. Mold did it first, though: https://github.com/rui314/mold https://github.com/rui314/mold edit: lld did it first, mold improved upon it A faster development cycle is one of the coolest improvements that Zig brings – lightning fast recompiles, bringing the native development cycle closer to web speed. More languages should get this capability, and Apple needs it for Swift to get instantly updating SwiftUI previews. Static linking is required to get the best performance: no linker runtime cost, cross-language LTO and dead code elimination If this optimization is generally applicable and developers find it worthwhile, I could imagine this making its way to GCC-land. At the very least, gold needs replacing/rewriting to be competitive now. edited: for clarity
    • ndesaulniers 3y ago
      > Mold did it first, though: https://github.com/rui314/mold https://github.com/rui314/mold Before LLD?
      • conradev 3y ago
        I had forgotten about LLD, you are right, but also, they’re from the same author! :P
      • covector 3y ago
        lld has parallelism here and there, as well as ld64. I do believe ld64 is technically the first linker that started parsing object files in parallel. Parallel linking was conjectured impossible for a while without breaking static archive semantics (AB-BA problem). Michael has a good explanation in https://www.youtube.com/watch?v=ONGVraXbJOo https://www.youtube.com/watch?v=ONGVraXbJOo (minute 3 and beyond).
        • duped 3y ago
          > Parallel linking was conjectured impossible for a while without breaking static archive semantics (AB-BA problem) Didn't Tera/Cray have a parallel linker back in the 90s?
• layer8 3y ago
  Whole-bundle signing wouldn’t need to prevent security updates of individual libraries to be loaded when provided on the side, similar to cryptexes.