Local Catalyst wheel build is broken on macOS

[dime10]

On my system (macOS 14 arm64), I can no longer build working wheels from a local repository. This is present on both v0.10 and v0.9. Besides changes in the Catalyst package, it could also be due to a change in build environment (OS or package updates).

The problem is down to the unique library ID of the custom_calls library as seen below (first line of a library is always itself):

otool -L PennyLane_Catalyst-0.9.0/catalyst/utils/libcustom_calls.so 
PennyLane_Catalyst-0.9.0/catalyst/utils/libcustom_calls.so (architecture x86_64):
        build/lib.macosx-10.9-universal2-cpython-311/catalyst/utils/libcustom_calls.so (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
PennyLane_Catalyst-0.9.0/catalyst/utils/libcustom_calls.so (architecture arm64):
        build/lib.macosx-10.9-universal2-cpython-311/catalyst/utils/libcustom_calls.so (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

while the library is originally generated with the correct identifier (@rpath/libcustom_calls.so), when packaged into the wheel the identifier changes to build/lib.macosx-10.9-universal2-cpython-311/catalyst/utils/libcustom_calls.so which will cause a dynamic linker error when loading the custom calls library during execution.

I briefly tested to see if delocate would fix the wheel, but it doesn't. Wheels on the CI seem as of yet unaffected by this.

[erick-xanadu]

@dime10 is this affecting the release?

[dime10]

@dime10 is this affecting the release?

Only insofar as it was blocking me from testing certain things, but no it's not release critical :)