[llvm-dev] contributing llvm-install-name-tool
Alexander Shaposhnikov via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 14 10:34:24 PDT 2019
"There are a few different approaches to implementing this, and I am not
particularly tied to one. I think that selecting the one that is in the
best interest of the project and the most maintainable long term would be
- I agree.
Regarding the implementation I can imagine different options here, but need
to take a closer look / play with the code a little bit to see how things
work. Hypothetical approaches: (A) build a standalone tool (similarly to
llvm-lipo) (B) extend llvm-objcopy & add a new "driver" (similarly to how
llvm-strip is implemented on top of llvm-objcopy) (in particular,
llvm-install-name-tool would be a symbolic link to llvm-objcopy). As I've
mentioned above - I need to take a closer look at the code before making a
decision / proposing a solution, there are different considerations on my
mind here, e.g. install-name-tool appears to be simpler than objcopy is,
and probably doesn't require the full power of the mutable model of an
object file (implemented inside llvm-objcopy).
On Mon, Oct 14, 2019 at 10:21 AM Saleem Abdulrasool <compnerd at compnerd.org>
> Hey Michael,
> I completely agree that setting the rpath properly the first time around
> is much preferred. But, changes to the binary, particularly during
> development is much quicker.
> Prebuilt libraries which are being repackaged is one use case that is
> In the past, I’ve even used it to repair am incorrectly built library
> which was missing the library name.
> There are a few different approaches to implementing this, and I am not
> particularly tied to one. I think that selecting the one that is in the
> best interest of the project and the most maintainable long term would be
> On Fri, Oct 11, 2019 at 10:12 PM Michael Trent <mtrent at apple.com> wrote:
>> Hi there,
>> 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.
>> Is there a use-case for install_name_tool that I have overlooked?
>> 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?
>> 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?
>> On Oct 11, 2019, at 10:31 AM, Alexander Shaposhnikov <
>> alexander.v.shaposhnikov at gmail.com> wrote:
>> Hey everyone!
>> 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 (
>> There is another useful utility called install_name_tool (see e.g.
>> https://www.unix.com/man-page/osx/1/install_name_tool/ ),
>> 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.
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev