Duplicate rpath handling in install_name_tool/otool
Duplicate rpath handling in install_name_tool/otool
- Subject: Duplicate rpath handling in install_name_tool/otool
- From: William Woodruff <email@hidden>
- Date: Wed, 27 Jul 2016 22:15:31 -0400
Hi Darwin Dev,
I'm developing a Mach-O parser in ruby for the Homebrew project [1],
and I noticed some potentially unintentional/unintuitive behavior in
install_name_tool's handing of rpath additions/modifications/deletions.
In particular, as of at least 10.11.5,
`install_name_tool -delete_rpath <path>` will only delete the first of
two or more duplicate rpath load commands. This is a departure from
earlier versions of install_name_tool, which would attempt to delete
all duplicate commands (but would fail to update the header's ncmds,
leaving the Mach-O in an inconsistent state) [2][3].
While the current behavior is certainly better than the aforementioned
corruption, it's also unintuitive - a user who sees that -delete_rpath
has completed successfully on a file with duplicated rpaths will
(incorrectly) think that the old runtime path is no longer being used.
Similarly, it's possible to circumvent install_name_tool's guard against
duplicate rpath addition by adding a different rpath, then using
`install_name_tool -rpath <new> <existing>`. This doesn't break the
binary, but it sets up the conditions above. It's also possible to
create duplicate rpaths in a binary by passing -rpath <path> to the
compiler/linker multiple times during the compilation process.
Can somebody at Apple confirm that this is the intended behavior?
Our approach with ruby-macho has been to remove all duplicates of an
rpath during deletion [4], and to employ guards on duplication during
addition/modification.
Thanks,
William Woodruff
P.S.: rpaths are the most glaring example of this since
install_name_tool provides options for adding and removing them
(and not just modifying them like dylib_commands). However, I'd
be extremely interested to learn whether or not binaries containing
other duplicated LCs (dylibs, version infos, etc) are considered
"broken" (even when they don't fail the linker/loader/otool).
[1]: https://github.com/Homebrew/ruby-macho
[2]: https://github.com/Homebrew/ruby-macho/issues/41#issuecomment-235475634
[3]: https://github.com/Homebrew/ruby-macho/issues/41#issuecomment-235683678
[4]: https://github.com/Homebrew/ruby-macho/pull/40
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden