Locate otool and install_name_tool with xcrun

[sfackler]

Changelog: Feature: The fix_apple_shared_install_name tool now uses xcrun to resolve the otool and install_name_tool programs.
Docs: Omit

Closes #14188

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[memsharded]

Thanks very much for your contribution.

I think this makes sense, and it is cleanly implemented.

It would be good to have some new unit test that validates a bit more the implementation (and ensures it is not broken in the future). Do you think you could add them? (no problem if you don't manage, we can contribute them). Thanks!

[jcar87]

Hi @sfackler - thank you for opening this PR.

I'm not entirely familiar with osxcross, but is there a chance it contains the xcrun tool? I believe the most agnostic way of handling this would be to invoke xcrun --find install_name_tool to derive the path to the tool. This is what happens implicitly on macOS when one runs /usr/bin/install_name_tools - so I think it would be correct on both macOS and otherwise to use xcrun instead.

Out of curiosity I wonder how osxcross handles this in general - the utility is called install_name_tool and that's what most build systems will assume, e.g. https://github.com/Kitware/CMake/blob/7bd24c1da5d093199dedab3fcfad6ec93d4c7aa5/Modules/Platform/Darwin.cmake#L71-L79 - it being rather tedious to have to change it everywhere (CMake, Conan, etc), due to the unconventional name.

[sfackler]

Yep, it does contain an unprefixed xcrun:

root@409d72e9166d:/# xcrun -find install_name_tool
/cross-macos-0.14.0-2-gf41a2bc-linux-x86_64/bin/x86_64-apple-darwin20.4-install_name_tool

I can update this to remove the confs and resolve install_name_tool and otool from xcrun if you'd prefer.

osxcross does ship a cmake toolchain that handles the install_name_tool name for that build system at least: https://github.com/tpoechtrager/osxcross/blob/564e2b9aa8e7a40da663d890c0e853a1259ff8b1/tools/toolchain.cmake#L41

Happy to add tests as well!

[memsharded]

Yep, it does contain an unprefixed xcrun:

Ok, that is great, thanks for checking.

I can update this to remove the confs and resolve install_name_tool and otool from xcrun if you'd prefer.

Yes, I think it would be better if the xcrun brings those tools automatically, and there is no need for extra confs. If you think you can do that, that would be amazing.

[sfackler]

Updated to use xcrun and remove the new confs.

[sfackler]

Alternatively, we could just prefix all of the commands with xcrun, e.g. xcrun otool -hv {file}

[memsharded]

I think it is good as is, thanks!

[memsharded]

I think it looks good, but I'll defer it to @jcar87 that knows more than me in OSX.

[memsharded]

I think it is good as is, thanks!

[memsharded]

Just curious (and possibly ignorance about how it works). How this XCRun connects to the specific osxcross environment? Via os.sdk setting? I guess that you have tested against your osxcross, and it works, but as it is not covered by full functional tests, I'd like to understand how it works.

[sfackler]

I think the xcrun has that relative SDK path hardcoded as the default search location when it was compiled, but I'm not totally sure.

On a semi-related note, I do need to explicitly set tools.apple:sdk_path for some CMake logic to work properly - would it be worth it to have the CMakeToolchain tool query XCRun for the SDK path if it's not explicitly configured?

[jcar87]

Awesome, thanks so much for your contribution @sfackler!

[memsharded]

Thanks for the contribution, this will be in next 2.0.8.

I am spinning a new issue from your comment above, I think it is necessary to follow up