Ensure that dynamic lib merge targets are unique.

[freakboy3742]

The candidate list for dylibs to be merged will not be unique; every dylib will be found twice. This may also be the cause of the CI failure.

Also ensures that the merge step only operates on single-platform wheels.

Fixes #1481

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

@mhsmith Hold off on reviewing this one - I've found another edge case related to dylib merging as a result of CI on beeware/toga#1399.

[freakboy3742]

Ok - I've now fixed the problem we are seeing in beeware/toga#1399's CI.

The problem is that pip will install platform specific binaries in preference to universal2 binaries. As a result, if a package publishes both x86_64 and universal2 binaries (which is a common configuration - fontTools is at least one example that does this), and you build your app on x86_64, the original app_packages install the single platform binary, discovers the need for an arm64 binary, which then installs a universal2 binary. When you try to merge the two, you get an error, because 2 of the libraries being merged have an x86_64 slice.

This fix does a thinning pass first, ensuring that all the libraries in the arm64 folder only contain arm64 components. This does result in some double handling - you get a universal binary, strip it, then make a universal binary... but there's no easy way I can think of to either (a) force the installation of a universal binary in the first place, or (b) make a decision to use existing the universal binary, rather than merge. The latter could potentially be done, but it's going to involve most of the same steps anyway (because you're going to have to inspect every binary to see if it's universal or not, then work out if using one of the binaries is an option, and if so, which one...), so I opted for the "strip then merge" approach.

[mhsmith]

That all makes sense, but why didn't it fail in #1475's pre-merge checks? Is it because it uses a thread pool, so the order of the lipo commands was non-deterministic?

[freakboy3742]

That all makes sense, but why didn't it fail in #1475's pre-merge checks? Is it because it uses a thread pool, so the order of the lipo commands was non-deterministic?

That's my best guess as well. When I run locally, I haven't been able to reproduce this error; and #1475 clearly had at least one CI pass (the last one) where it wasn't an issue. I'm guessing that the slower x86_64 CI machines are more prone to this problem, which is why we're seeing it manifest on most(?) CI runs.