Open rickmark opened 2 years ago
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
:slightly_smiling_face:
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: https://github.com/gimli-rs/object/issues/358
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 iOShttps://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#358https://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 GitHubhttps://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 unsubscribehttps://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: @.***>
Sounds good!
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::DSCFile
s. 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)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
A pure ruby implementation of these is useful as loose dylibs no longer exist on Apple platforms