morningman opened a new pull request, #66808:
URL: https://github.com/apache/doris/pull/66808

   ### What problem does this PR solve?
   
   Related PR: #66783, #66800
   
   Problem Summary:
   
   Picks up 
[apache/doris-thirdparty#408](https://github.com/apache/doris-thirdparty/pull/408),
 tagged as `hadoop-3.4.2.4-for-doris`. The single change over 
`hadoop-3.4.2.3-for-doris` is that macOS no longer builds `libhdfspp`.
   
   That library does not link on macOS. It is compiled against Homebrew LLVM's 
libc++ headers, which are configured with 
`_LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS 0`, so `std::exception_ptr`'s 
post-macOS-14 entry points are emitted whatever `-mmacosx-version-min` says, 
while `-lc++` still resolves against the SDK's system libc++. Against a macOS 
14 SDK that leaves `__cxa_init_primary_exception` and 
`std::exception_ptr::__from_native_exception_pointer` undefined, and the 
failing dylib takes the whole `make` down with it — `libhdfs.a` included:
   
   ```
   Undefined symbols for architecture arm64:
     "std::exception_ptr::__from_native_exception_pointer(void*)", referenced 
from:
         std::__1::promise<hdfs::Status>::~promise() in filesystem_sync.cc.o
         ...
   ld: symbol(s) not found for architecture arm64
   make[2]: *** [native/target/usr/local/lib/libhdfspp.0.1.0.dylib] Error 1
   ```
   
   Doris never links libhdfspp — `be/CMakeLists.txt:251` sets `BUILD_LIBHDFSPP 
OFF` — so the fork now stops after the x-platform object libraries `libhdfs` 
pulls out of that tree. `libhdfs.a`, `libhdfs.dylib`, `libhadoop.dylib`, 
`hdfs.h` and the jars are all unchanged.
   
   Linux is unaffected by the fork change, so this bump is a no-op there beyond 
the new tag. It is a prerequisite for #66800, which is where a macOS 
third-party build starts producing `lib/hadoop_hdfs_3_4/` and therefore where 
the failure above shows up — on the `macos-14` runner specifically. Note that 
master's `build-thirdparty.sh` still leaves `hadoop_libs_3_4` out of the macOS 
package list, so the macOS legs of this PR's CI do not exercise the fork change 
yet; #66800 is what turns it on.
   
   ### Release note
   
   None
   
   ### Check List (For Author)
   
   - Test
       - [x] Manual test (add detailed scripts or steps below)
   
       The fork was built end to end on macOS 26.5 / arm64 with the toolchain 
the macOS CI uses (Homebrew `llvm@20`, CMake 3.22.1, JDK 17, 
`MACOSX_DEPLOYMENT_TARGET=12.0`) before the tag was cut — hadoop-common-project 
9/9, hadoop-hdfs-project 7/7, hadoop-dist all `BUILD SUCCESS`, producing
   
       ```
       lib/native/  libhadoop.dylib 159K   libhadoop.a 753K
                    libhdfs.dylib   133K   libhdfs.a   1.4M    arm64
       include/     hdfs.h
       ```
   
       with no `libhdfspp.dylib` (8.9M previously), and `libhdfs.a` still 
exporting `hdfsSetLogger`, `hdfsGetLastExceptionRootCause`, 
`hdfsBuilderSetKerb5Conf`, `hdfsBuilderSetKeyTabFile`, `hdfsUnbufferFile`, 
`hdfsFileGetReadStatistics`, `hdfsHSync` and `hdfsHFlush`.
   
       The tarball this PR points at was downloaded twice; the MD5 is stable 
and the archive unpacks to `doris-thirdparty-hadoop-3.4.2.4-for-doris/` as 
`HADOOP_LIBS_3_4_SOURCE` expects.
   
   - Behavior changed:
       - [x] No. Linux builds byte for byte the same library set; macOS drops a 
library nothing links.
   
   - Does this need documentation?
       - [x] No.
   


-- 
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]

Reply via email to