Consider using macholib instead of native otool and install_name_tool

[pombredanne]

@ronaldoussoren https://github.com/ronaldoussoren/macholib is mature and has been around for eons and works. IMHO it would be better and more portable to use that so I could run delocate on Linux to fix mac wheels there rather than to have a mac on hand.

[HexDecimal]

Macholib seems to lack @rpath support for library lookups. ronaldoussoren/macholib#2

There also needs to be a replacement for the codesign utility if the goal is to make delocate portable.

[ronaldoussoren]

Depends on what you mean by "support". The lack of support in the issue mentioned earlier is lack of support for "@rpath" in the MachOStandalone feature (which is basically delocate, but for app bundles). That feature would not have to be used, you could just use the lower-level code for rewriting mach-o headers.

[HexDecimal]

I was just hoping that something here in the docs could replace a lot of the library search code I wrote, but @rpath isn't mentioned there.

[isuruf]

You can get install_name_tool and otool from https://github.com/tpoechtrager/cctools-port.
You can use ldid instead of codesign on Linux.

[jvolkman]

If anyone is still interested in this topic, I implemented pure-python replacements for otool, install_name_tool, and codesign (ad-hoc only) on top of macholib over at https://github.com/jvolkman/repairwheel/blob/main/src/repairwheel/macos/machotools.py

[matthew-brett]

That sounds like an interesting addition. I guess the execution speed is basically the same (but avoiding the overhead of subprocess.call)?

[jvolkman]

I haven't compared speed to be honest, although when operating on normal sized wheels any difference would appear to be negligible. My primary goal cross-platform support (so that I can repair a macos wheel on linux, for example). But I suppose not having to parse otool output is a nice plus.