zlib: Remove fdopen #defines.

[pcanal]

This applies madler/zlib@4bd9a71 from upstream.

fdopen() is not used by zlib anymore. The #defines are vestigial.

This make the build with builtin zlib fails on lastest MacOS/XCode

[github-actions]

Test Results

    18 files      18 suites   5d 0h 30m 32s ⏱️
 2 717 tests  2 716 ✅ 0 💤 1 ❌
47 211 runs  47 210 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 12392fa.

[dpiparo]

Thanks for these changes, that we'll need for 6.32 and 6.34 as well. Mac14 failed for a blas-related error. @lmoneta @guitargeek wouldn't this be fixed by #18257 ? Is something else needed?

[guitargeek]

De facto my PR is unrelated to the macOS 14 failures. The failures just reminded us that BLAS is also used in the PyMVA tests.

The problem with macOS 14 is that it actually finds the BLAS (here the extract from the logs, if it wouldn't find it there would be a warning about not building some PyMVA tests):

2025-04-05T00:27:31.8263110Z -- Looking for libuuid
2025-04-05T00:27:31.8806610Z -- Looking for BLAS as an optional testing dependency of TMVA-SOFIE
2025-04-05T00:27:31.9296150Z -- Looking for Protobuf
2025-04-05T00:27:31.9346080Z -- Looking for BLAS for optional parts of TMVA
2025-04-05T00:27:31.9346970Z -- Using GSL CBLAS for optional parts of TMVA
2025-04-05T00:27:31.9347440Z -- Looking for BLAS as an optional testing dependency of PyMVA
2025-04-05T00:27:31.9786060Z -- PyROOT: development package found. Building for version 3.9.6
2025-04-05T00:27:32.0521020Z -- Looking for PySpark dependency: Java

So it finds the BLAS with the official find_package(BLAS) from CMake, then we link against the provided BLAS::BLAS target, but it still fails:

2025-04-05T01:18:34.9929930Z Consolidate compiler generated dependencies of target TestRModelParserPyTorch
2025-04-05T01:18:35.0419360Z make[2]: *** No rule to make target `/opt/local/lib/libopenblas.dylib', needed by `tmva/pymva/test/TestRModelParserPyTorch'.  Stop.
2025-04-05T01:18:35.0440040Z make[2]: *** Waiting for unfinished jobs....

Indeed, connecting to the build node macphsft18, I can see that this file doesn't exist. How can this be the file that find_package(BLAS) identified? Has someone in the meantime uninstalled openblas from that machine to fix the problem?

That would be the right solution I think.