gh-144942: Fix macOS dylib build by adding $(MODLIBS) and removing -undefined dy… - #145186

See python/cpython#145186

See python/cpython#145186

See python/cpython#145186

…ork (#159966)

The rules that link `libpython$(LDVERSION).dylib` and the macOS and iOS frameworks don't pass `$(MODLIBS)`, unlike the `libpython$(LDVERSION).so` rule. When a module is built in, for example via `Modules/Setup.local`, the libraries that module needs are left out:

- **`--enable-framework`:** the build fails with undefined symbols.
- **`--enable-shared`:** the dylib is linked with `-undefined dynamic_lookup`, so the build succeeds and the failure only shows up at runtime.

To reproduce, build on macOS with this `Modules/Setup.local`:

```
*static*
_blake2 blake2module.c
```

On `main`:

- **`--enable-framework`:** linking `Python.framework` fails with 12 undefined `_Py_LibHacl_*` symbols.
- **`--enable-shared`:** `nm -u libpython3.16.dylib` lists the same 12 symbols. After `make install`, `python3 -c "import _blake2; _blake2.blake2b(b'abc')"` aborts with `dyld: missing symbol called`, and so does a C program that embeds Python.

With this change, both builds link with no undefined HACL symbols, and `_blake2` works as a built-in module. In default builds `$(MODLIBS)` is empty, so they are unaffected. `test_hashlib`, `test_hmac`, `test_embed` and `test_sysconfig` pass for shared and framework builds, both with and without the `Setup.local` above (macOS 14, arm64). I haven't tested the iOS framework rule, which gets the same one-line change.

python-build-standalone already carries the dylib part of this as a patch ([astral-sh/python-build-standalone#870](astral-sh/python-build-standalone#870)). This PR doesn't remove `-undefined dynamic_lookup`, as the earlier gh-145186 did.

… framework (GH-159966) (#160160)

gh-144942: Link `$(MODLIBS)` into the macOS shared library and framework (GH-159966)

The rules that link `libpython$(LDVERSION).dylib` and the macOS and iOS frameworks don't pass `$(MODLIBS)`, unlike the `libpython$(LDVERSION).so` rule. When a module is built in, for example via `Modules/Setup.local`, the libraries that module needs are left out:

- **`--enable-framework`:** the build fails with undefined symbols.
- **`--enable-shared`:** the dylib is linked with `-undefined dynamic_lookup`, so the build succeeds and the failure only shows up at runtime.

To reproduce, build on macOS with this `Modules/Setup.local`:

```
*static*
_blake2 blake2module.c
```

On `main`:

- **`--enable-framework`:** linking `Python.framework` fails with 12 undefined `_Py_LibHacl_*` symbols.
- **`--enable-shared`:** `nm -u libpython3.16.dylib` lists the same 12 symbols. After `make install`, `python3 -c "import _blake2; _blake2.blake2b(b'abc')"` aborts with `dyld: missing symbol called`, and so does a C program that embeds Python.

With this change, both builds link with no undefined HACL symbols, and `_blake2` works as a built-in module. In default builds `$(MODLIBS)` is empty, so they are unaffected. `test_hashlib`, `test_hmac`, `test_embed` and `test_sysconfig` pass for shared and framework builds, both with and without the `Setup.local` above (macOS 14, arm64). I haven't tested the iOS framework rule, which gets the same one-line change.

python-build-standalone already carries the dylib part of this as a patch ([astral-sh/python-build-standalone#870](astral-sh/python-build-standalone#870)). This PR doesn't remove `-undefined dynamic_lookup`, as the earlier gh-145186 did.
(cherry picked from commit 03864a2)

Co-authored-by: Itamar Oren <itamarost@gmail.com>

… framework (GH-159966) (#160158)

gh-144942: Link `$(MODLIBS)` into the macOS shared library and framework (GH-159966)

The rules that link `libpython$(LDVERSION).dylib` and the macOS and iOS frameworks don't pass `$(MODLIBS)`, unlike the `libpython$(LDVERSION).so` rule. When a module is built in, for example via `Modules/Setup.local`, the libraries that module needs are left out:

- **`--enable-framework`:** the build fails with undefined symbols.
- **`--enable-shared`:** the dylib is linked with `-undefined dynamic_lookup`, so the build succeeds and the failure only shows up at runtime.

To reproduce, build on macOS with this `Modules/Setup.local`:

```
*static*
_blake2 blake2module.c
```

On `main`:

- **`--enable-framework`:** linking `Python.framework` fails with 12 undefined `_Py_LibHacl_*` symbols.
- **`--enable-shared`:** `nm -u libpython3.16.dylib` lists the same 12 symbols. After `make install`, `python3 -c "import _blake2; _blake2.blake2b(b'abc')"` aborts with `dyld: missing symbol called`, and so does a C program that embeds Python.

With this change, both builds link with no undefined HACL symbols, and `_blake2` works as a built-in module. In default builds `$(MODLIBS)` is empty, so they are unaffected. `test_hashlib`, `test_hmac`, `test_embed` and `test_sysconfig` pass for shared and framework builds, both with and without the `Setup.local` above (macOS 14, arm64). I haven't tested the iOS framework rule, which gets the same one-line change.

python-build-standalone already carries the dylib part of this as a patch ([astral-sh/python-build-standalone#870](astral-sh/python-build-standalone#870)). This PR doesn't remove `-undefined dynamic_lookup`, as the earlier gh-145186 did.
(cherry picked from commit 03864a2)

Co-authored-by: Itamar Oren <itamarost@gmail.com>