Support for `dyld_shared_cache` files

[rickmark]

A pure ruby implementation of these is useful as loose dylibs no longer exist on Apple platforms

[woodruffw]

That would be interesting, although I want to take care not to make API concessions that get in the way of Homebrew's uses of ruby-macho 🙂

If we can add support without making their usecases more difficult, I'm all for it.

Someone did a partial writeup on the newer shared cache format here: gimli-rs/object#358

[rickmark]

Plan was to introduce as a separate file / class like FAT so it’s broadly isolated - it has a separate magic so the global open could return it based on detection Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: William Woodruff ***@***.***> Sent: Thursday, January 13, 2022 5:51:01 PM To: Homebrew/ruby-macho ***@***.***> Cc: Rick Mark ***@***.***>; Author ***@***.***> Subject: Re: [Homebrew/ruby-macho] Support for `dyld_shared_cache` files (Issue #434) That would be interesting, although I want to take care not to make API concessions that get in the way of Homebrew's uses of ruby-macho 🙂 If we can add support without making their usecases more difficult, I'm all for it. Someone did a partial writeup on the newer shared cache format here: gimli-rs/object#358<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgimli-rs%2Fobject%2Fissues%2F358&data=04%7C01%7C%7C15baa4e251b74042a2e308d9d7005166%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777218630764131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mH13eHffe42TKd%2FlsfvxXkBiqGJ%2FHjXJzjldlhr2Dx4%3D&reserved=0> — Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHomebrew%2Fruby-macho%2Fissues%2F434%23issuecomment-1012676303&data=04%7C01%7C%7C15baa4e251b74042a2e308d9d7005166%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777218630764131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UBxcXcKmDaHb32kmtI4Rm2BIrpN66B7WEHiYBn%2FyMAo%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA6TW6JVA5QDISA4OWSXRDUV56QLANCNFSM5L5NKVZA&data=04%7C01%7C%7C15baa4e251b74042a2e308d9d7005166%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637777218630764131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZHuST%2Bst2RzGq5ZP9pjjEgtVwDyM%2Ff9m%2F71aktQelc0%3D&reserved=0>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[woodruffw]

Sounds good!

[rickmark]

Started to work through this implementation.

macOS 12 has DSCs that are multi file now, so the plan is to create MachO::DyldSharedCache class which is a collection of 1 or more MachO::DyldSharedCache::DSCFiles. You can then loop over the DSC to get each of the embedded dylibs.

In order to fully emulate the dsc_extractor.bundle behavior we would need to correctly handle the pre-binding by regenerating exports and imports. This seems far easier when a sideband .symbols file is present (it appears to contain the symbolic names that get optimized away by the prebinding)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.