Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using macholib instead of native otool and install_name_tool #73

Open
pombredanne opened this issue May 14, 2020 · 7 comments
Open

Comments

@pombredanne
Copy link

@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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

isuruf commented Jul 17, 2021

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
Copy link
Contributor

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
Copy link
Owner

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

@jvolkman
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants