tree 1bac6a8bf008c87ee9d1740fdac0c491f3094d5f
parent a3d3efd3cfc6e9b0ce8a7536527e1e9ca134f80a
author Ralf Gommers <ralf.gommers@gmail.com> 1718720535 +0200
committer Eli Schwartz <eschwartz93@gmail.com> 1718728987 -0400

Improve `nm` usage in symbolextractor script on macOS

This fixes the unit test `TestAllPlatformTests.test_noop_changes_cause_no_rebuilds`,
when run with an `nm` binary from `cctools-port` (as shipped by conda-forge, see
https://github.com/conda-forge/cctools-and-ld64-feedstock).

It also addresses the issue discussed in https://github.com/mesonbuild/meson/discussions/11131,
and this build warning:
```
[48/1383] Generating symbol file scipy/special/libsf_error_state.dylib.p/libsf_error_state.dylib.symbols
WARNING: ['arm64-apple-darwin20.0.0-nm'] does not work. Relinking will always happen on source changes.
error: arm64-apple-darwin20.0.0-nm: invalid argument --
```
as reported in scipy#20740.

The unit test traceback was:
```
>       self.assertBuildRelinkedOnlyTarget('mylib')
E       AssertionError: Lists differ: ['mylib', 'prog'] != ['mylib']
E
E       First list contains 1 additional elements.
E       First extra element 1:
E       'prog'
E
E       - ['mylib', 'prog']
E       + ['mylib']

unittests/allplatformstests.py:1292: AssertionError
```

The `nm` shipped by Apple yields the exact same results either way; the man page for `nm`
only lists the single-character form so this seems preferred either way.