gh-59703: use the dladdr instead of deprecated macOS APIs in getpath.c

[aisk]

The GA does not run the tests with --enable-framework, so how can we test the change?

• Issue: Eliminate the use of deprecated OS X APIs in getpath.c #59703

[ned-deily]

@python/macos-team

[ronaldoussoren]

The GA does not run the tests with --enable-framework, so how can we test the change?

Could you explain what you mean?

[chrstphrchvz]

The GA does not run the tests with --enable-framework, so how can we test the change?

Could you explain what you mean?

I am not the PR author, but to try to explain this: the proposed changes to getpath.c affect code which is only compiled when WITH_NEXT_FRAMEWORK is defined, which is only the case when the configure script is run with --enable-framework. But the GitHub Actions CI for macOS does not do this, so the proposed changes have not been fully tested by the CI.

[ronaldoussoren]

A relevant issue for this is #59703, which contains an ancient patch that uses basically the same solution (but is outdated otherwise).

@ned-deily : is this something you can easily test on a number of macOS versions? I can currently only test on macOS 14 and 13, and I'd prefer to have test results on at least one version before 11.0 before changing the way we merge this.

[ned-deily]

Will do

[ned-deily]

To test, I cherry-picked the PR to the current head of 3.12 and built a current python.org-style 10.9+ universal2 installer. I then installed on and ran the usual test suite on: macOS 14.1 (Apple Silicon and Intel), macOS 11 (Apple Silicon), macOS 10.13 (Intel), and macOS 10.9 (Intel). I did not notice any regressions from the 3.12.0 release. So, while not a comprehensive test and not testing any effects on embedded uses, I think we could go ahead with this for 3.13.

[ned-deily]

FTR, this PR introduced a regression for older macOS releases that was corrected by #112309. Both PRs were included in 3.13.0a2.