Ship linkable libraries in the macOS wheel

[shoumikhin]

The macOS wheel shipped one fused Python extension and no linkable libraries, so a
C++ application got nothing from it: the headers and the CMake package were there, but
every component a consumer asked for resolved to nothing. On Linux the same wheel
ships the runtime, the kernels, the delegates, the thread pool and the profiler as
separate libraries, and a C++ application links them directly.

The three mechanisms that made this Linux only now have Mach-O equivalents:

runtime search path   $ORIGIN            @loader_path
keeping a registration
only library linked   --no-as-needed     -force_load, already present
library identity      ELF soname         install name relative to @rpath

Windows is still refused, because there the runtime carries no export annotations for
a DLL, which is a missing capability rather than a different spelling of one.

The packaging entries and the package config asked for a .so by name, so they would
have looked for a file the build never emits. Both now derive the suffix from the
platform, and the config also accounts for Mach-O putting the version before the
suffix, libfoo.1.dylib, where ELF puts it after, libfoo.so.1.

The two wheel test suites now run on macOS as well, which is what makes the split
verified rather than claimed: the Python extension links these libraries itself, so it
passes whether or not the package config names them or the shipped headers are
complete. Porting them needed a suffix helper, the Mach-O spelling of the symbol
queries, since nm -D asks for a dynamic symbol table that Mach-O does not have, and
otool in place of readelf. One check keeps a documented skip on macOS: ldd resolves
dependencies transitively and reports undefined symbols, and otool -L only lists
recorded names, so claiming equivalence there would weaken the check while appearing
to strengthen coverage.

Test Plan: exercised both platform branches of every changed helper.

The CMake helpers, driven with real CMake and the Apple branch forced, so the macOS
answers are checked rather than assumed:

shipped runtime path   Linux $ORIGIN                  macOS @loader_path
two entry path         Linux $ORIGIN/../../lib:...    macOS @loader_path/../../lib;...
library identity       Linux version only             macOS install name @rpath

The Python helpers, loaded under each platform:

suffix                 .so                            .dylib
defined symbols        nm -DC                         nm -gU -C
undefined symbols      nm -DC --undefined-only        nm -gu -C
library file name      libexecutorch.so               libexecutorch.dylib

The symbol queries and the load command reader were then run against a real Mach-O
library on macOS: 137 defined and 133 undefined symbols listed, and the load commands
read, including the dependency and search path entries and the torch dependency the
libtorch check looks for.

Linux is unaffected, verified by building a wheel from this change and confirming it
still ships the same six libraries.

[shoumikhin]

Stack from ghstack (oldest at bottom):

• -> Ship linkable libraries in the macOS wheel #21771
• Ship the OpenVINO delegate as its own library #21770
• Build and publish CUDA wheels #21668
• Ship the CUDA delegate in the wheel #21645
• Ship the quantized kernels as their own library #21642
• Ship a C++ SDK in the wheel #21639
• Split the runtime out of the Python bindings extension #21610

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21771

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.