load_commands: add LC_LAZY_LOAD_DYLIB_INFO

[Bo98]

Fresh from the macOS 26.4 SDK.

Or fresh in that I committed this based on the beta last month but waited for final release to run git push.

[Copilot]

Pull request overview

Adds support for a newly introduced Mach-O load command constant so the library can recognize and parse binaries produced with newer macOS SDKs.

Changes:

• Add LC_LAZY_LOAD_DYLIB_INFO (0x3a) to the load-command ID → symbol mapping.
• Map LC_LAZY_LOAD_DYLIB_INFO to LinkeditDataCommand in the symbol → structure mapping.
• Update LinkeditDataCommand documentation to include the new command.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[p-linnane]

Fresh 😎

[woodruffw]

Thanks @Bo98! Is there a binary we can use for test of this?

[Bo98]

I'm not aware of any linker option to actually output these binaries. It might become clearer when dyld and/or cctools source code is released for macOS/Xcode 26.4, though the new linker is more and more closed source nowadays.

It's also possible it might only be activated with macOS 27. We've seen that before. Or just end up a mystery like LC_TARGET_TRIPLE.

[Bo98]

Is there a binary we can use for test of this?

Xcode 26.4 now contains hidden, undocumented options for this.

And indeed it seems I'm right that it will be a macOS 27 thing despite shipping with Xcode 26.4 and associated runtime symbols being in the macOS 26.4:

$ clang -I/opt/homebrew/include -L/opt/homebrew/lib -lazy-lssl -mmacosx-version-min=26.4 test.c
ld: warning: lazy-load will be ignored for 'ssl' because deployment target version is too low

$ clang -I/opt/homebrew/include -L/opt/homebrew/lib -lazy-lssl -mmacosx-version-min=27.0 test.c

$ otool -l a.out
[...]
Load command 15
      cmd LC_LAZY_LOAD_DYLIB_INFO
  cmdsize 16
  dataoff 49304
 datasize 88
[...]

$ dyld_info a.out
a.out [arm64]:
    -platform:
        platform     minOS      sdk
           macOS     27.0      26.4   
[...]
    -linked_dylibs:
        attributes     load path
                       /usr/lib/libSystem.B.dylib
        lazy-load      /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib

Makes me wonder if it's time to think about parsing these linkedit load commands. Do we want brew linkage to pick up these lazy-loaded dylibs? Too early to tell until we know the use case as we don't know how it differs from delay-init. WWDC's not far away anyway.

Interesting it's a new command when macOS 15 already added a flag field to LC_LOAD_DYLIB that is used for all other attributes liked delay-init, but there's maybe some performance reason for it. LC_LAZY_LOAD_DYLIB also exists but that's for the old -lazy-l they deprecated in Xcode 11.