Thank you for chiming in! LTO wouldn't really matter for "delinking" exported symbols of shared libraries though, would it? The exported functions must necessarily follow platform ABI convention, and so long as those are copied over, things would seem to work fine.
I guess the one catch with shared libraries is that if shared library A itself depends on another dylib B, then calls within A to functions of B would go via PLT indirection. So then creating an object file out of this would involve not just moving code and creating relocation entry but also possibly patching the assembly itself to remove the call indirection.
If you're delinking the entire LTO-optimized shared library as one big blob, then sure. LTO effectively turns a program/library into one huge translation unit, but if you're not cutting across it then the platform ABI mandates the observable boundary.
I guess the one catch with shared libraries is that if shared library A itself depends on another dylib B, then calls within A to functions of B would go via PLT indirection. So then creating an object file out of this would involve not just moving code and creating relocation entry but also possibly patching the assembly itself to remove the call indirection.