New otool output is not tested directly.

[HexDecimal]

Issue #78 involved a breaking change in the output of otool. This was fixed in #130 but I couldn't reproduce this output on the any of the GitHub Runners, and I don't know how to upgrade the tools to test the newer output.

Any new information on this would be helpful such as which versions of otool/macOS made this change to the output.

For example, a universal2 object has this style of output from the older tools:

❯ otool -L foo.so
foo.so:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

And this output from the newer tools:

❯ otool -L foo.so
foo.so (architecture x86_64):
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
foo.so (architecture arm64):
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

[matthew-brett]

Draft at #140

[mayeut]

The GHA runners provide (today) 7 versions of Xcode installed on macOS-11 and 13 versions installed on macOS-10.15:
https://github.com/mayeut/delocate/runs/4681900037?check_suite_focus=true

It might be good to check on a regular basis that new versions (and there will be as runners are updated) that delocate can work with all of them ?
Maybe as a way to generate a subset of the data used by the mock being drafted in #140 (in addition to other data received in #78) ?

[HexDecimal]

The inconsistent behavior between otool versions seems to come from a missing -arch all flag in the main call to otool. I think adding this flag will resolve this issue.