<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi there,<div class=""><br class=""></div><div class="">This tool has been around for a long time. Originally it gave people a way to move a dylib to a new location without rebuilding, and then as a way to make an existing dylib embeddable (@rpath). I wonder if this tool is really necessary. It’s always better to make the dylib with the correct install name at build time, including @rpath, etc.. Most dylibs we see any more are either installed in fixed file system locations by OS vendors (i.e., Apple) or are embedded @rpath dylibs installed by everyone else. </div><div class=""><br class=""></div><div class="">Is there a use-case for install_name_tool that I have overlooked?</div><div class=""><br class=""></div><div class="">Or Is that small set of dylibs meant to be installed in fixed file system locations large / complex enough that people really need to install them in many different locations without simply relinking the files? </div><div class=""><br class=""></div><div class="">Turning to practical matters, is your intent to have the load-command rewriting code live in the tool? Or are you proposing adding support for building/swapping/rewriting Object files to libObject?</div><div class=""><br class=""></div><div class="">MDT</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 11, 2019, at 10:31 AM, Alexander Shaposhnikov <<a href="mailto:alexander.v.shaposhnikov@gmail.com" class="">alexander.v.shaposhnikov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="margin: 0px; padding: 0px; border: 0px; font-size: 13px; white-space: pre-wrap;" class="">Hey everyone!</span><span style="font-size:13px" class=""> </span> <div class="">Recently there has been some progress on LLVM-based tools for manipulating MachO binaries: llvm-objcopy has been gaining a lot of important bits to support MachO (it's relatively close to the point where one can implement the strip-like functionality), llvm-lipo is functional and supports most of cctools' lipo options (<a href="https://llvm.org/docs/CommandGuide/llvm-lipo.html" class="">https://llvm.org/docs/CommandGuide/llvm-lipo.html</a>). </div><div class="">There is another useful utility called install_name_tool (see e.g. <a href="https://www.unix.com/man-page/osx/1/install_name_tool/" class="">https://www.unix.com/man-page/osx/1/install_name_tool/</a> ),</div><div class="">this tool is capable of changing the rpaths, the names of the dependent shared libraries, etc. The way it works - install-name-tool (from cctools) generates the new list of MachO load commands and the new MachO header, the other parts of the binary are copied over (in particular, if I'm not mistaken, it assumes that the new "prefix" (MachO header + load commands) fits into the binary so the offsets don't need to be recalculated, otherwise suggests to relink the binary with -headerpad / -headerpad_max_install_names / reports an error). One possible (and simple) approach is to implement llvm-install-name-tool in a similar fashion: use libObject to parse the input binary and rebuild the list of load commands (analogously to what cctools' install_name_tool does (and with the same limitations)). I'd like to ask for your general feedback / thoughts / suggestions on contributing llvm-install-name-tool to LLVM with the goal to be a drop-in replacement for cctools' install_name_tool. </div><div class="">Thanks,</div><div class="">Alex</div></div>
</div></blockquote></div><br class=""></div></body></html>