morningman opened a new pull request, #407:
URL: https://github.com/apache/doris-thirdparty/pull/407
## What
Two `if(APPLE)` guards that let `mvn -Pnative` finish on macOS. The Linux
path is byte for byte unchanged.
## Why
Both failures are platform differences, not defects in the tree.
### 1. `find_package(ZLIB REQUIRED)` cannot succeed on modern macOS
`hadoop-common/src/CMakeLists.txt` calls
`hadoop_set_find_shared_library_version("1")` before the lookup, which pins
`CMAKE_FIND_LIBRARY_SUFFIXES` to `.1.dylib`. macOS keeps no `libz.1.dylib` on
disk any more — libz lives in the dyld shared cache, and the SDK carries only a
`libz.1.tbd` stub — so the `REQUIRED` lookup fails and configure aborts:
```
CMake Error at .../FindPackageHandleStandardArgs.cmake:290 (message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.12")
Call Stack (most recent call first):
.../FindZLIB.cmake:242 (find_package_handle_standard_args)
CMakeLists.txt:49 (find_package)
```
zlib is never linked into libhadoop; only its headers are used
(`CMakeLists.txt:268`). The library name is consumed purely as a **runtime**
`dlopen` argument — `ZlibCompressor.c:108` does `dlopen(HADOOP_ZLIB_LIBRARY,
RTLD_LAZY | RTLD_GLOBAL)` — and `dlopen("libz.1.dylib")` does resolve against
the shared cache. Confirmed on macOS 26.5:
```
dlopen(libz.1.dylib) = 0x364c73c68 err=none
dlsym(deflate) = 0x197124d38
```
So on APPLE the patch drops the suffix pin (CMake's default macOS suffix
list already includes `.tbd`, which finds the SDK stub and its headers) and
names the runtime library outright. The resulting `libhadoop.dylib` carries
`libz.1.dylib` as its dlopen string.
### 2. `libhdfspp.dylib` fails to link, taking `libhdfs.a` with it
libhdfspp's shared library links a static libsasl2 whose GSSAPI plugin
leaves 22 `gss_*` symbols undefined:
```
"_gss_init_sec_context", referenced from:
_gssapi_client_mech_step in libsasl2.a[20](gssapi.o)
...
ld: symbol(s) not found for architecture arm64
make[2]: *** [native/target/usr/local/lib/libhdfspp.0.1.0.dylib] Error 1
```
Linux' `ld` tolerates undefined symbols in a `.so`; macOS' `ld` does not.
The failing target is only libhdfspp's dylib, but it fails the whole `make`, so
`libhdfs.a` never reaches the dist step. SASL is used by libhdfspp alone, so
the patch sets `NO_SASL` — the escape hatch `libhdfspp/CMakeLists.txt:121-122`
already documents.
Skipping the `libhdfspp` subdirectory outright is **not** a workable
alternative: `libhdfs/CMakeLists.txt:35` pulls
`$<TARGET_OBJECTS:x_platform_obj>` out of that tree, and dropping it yields `No
SOURCES given to target: hdfs`.
## Verification
macOS 26.5 / arm64, llvm@20, JDK 17, tested with both cmake 3.25.3 (the
version pinned by Doris' macOS CI) and cmake 4.4. Dependencies resolved from a
Doris thirdparty prefix; no extra Homebrew packages needed.
`build.sh` completes end to end — hadoop-common-project 9/9,
hadoop-hdfs-project 7/7, hadoop-dist — and produces:
```
hadoop-libhdfs-3.4.2/native/ libhdfs.a 1.4M arm64
libhadoop.dylib 160K arm64
libhdfs.dylib 135K arm64
libhdfspp.dylib 8.9M arm64
include/ hdfs.h
```
`libhdfs.a` exports the full API its consumers need, including this fork's
`hdfsSetLogger`, plus `hdfsGetLastExceptionRootCause`,
`hdfsBuilderSetKerb5Conf`, `hdfsBuilderSetKeyTabFile`, `hdfsUnbufferFile`,
`hdfsFileGetReadStatistics`, `hdfsHSync` and `hdfsHFlush`.
Linux is unaffected: every changed line sits inside an `if(APPLE)` / `if(NOT
APPLE)` branch.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
