zy-kkk opened a new pull request, #69231: URL: https://github.com/apache/doris/pull/69231
### What problem does this PR solve? Issue Number: N/A Related PR: N/A Problem Summary: Large BE binaries can fail to link on macOS ARM64 with gperftools 2.10: ```text ld: fixup error (kind=arm64_b26) at '_tc_free'+0x40 B/BL out of range (displacement=-265493668, max is +/-128MB) ``` gperftools 2.10 places allocator functions in custom Mach-O sections, `google_malloc` and `malloc_hook`, without the pure-instructions attribute. This affects branch island placement in large binaries. As the BE grows, the branch from `tc_free` toward `perftools_pthread_getspecific` can exceed the ARM64 ±128 MiB range. Upgrade gperftools from 2.10 to 2.18.1. Upstream removed the macOS `ATTRIBUTE_SECTION` mechanism in [5472781](https://github.com/gperftools/gperftools/commit/5472781f4ae2e4f32b667eabc15f70c267f429e8), eliminating the custom sections responsible for this layout issue. Using the upstream fix avoids maintaining a local section-attribute patch or linker workaround. Update the download URL, archive name, source directory and checksum in `thirdparty/vars.sh`. ### Release note Fix macOS ARM64 BE link failures caused by out-of-range branches in gperftools 2.10 by upgrading to gperftools 2.18.1. ### Check List (For Author) - Test - [ ] Regression test - [x] Unit Test: all 45 upstream gperftools tests passed. - [x] Manual test (add detailed scripts or steps below) - On macOS ARM64, built gperftools with LLVM 20 and Doris with LLVM 22.1.8. - Passed allocator and profiling API probes, including allocation/reallocation, memory properties and release, heap profiles and CPU sampling. - Passed `BUILD_TYPE=Release USE_JEMALLOC=OFF bash ./build.sh --be -j 8` and `BUILD_TYPE=ASAN bash ./build.sh --be -j 8`, including packaging and `doris_be --version` checks. - Confirmed that the Release BE contains tcmalloc and CPU-profiler definitions and no affected custom sections. - Separately on branch-4.2, passed full FE/BE Release builds, upgraded and started the local instance, verified FE/BE health, and executed `SELECT SUM(number) FROM numbers('number'='1000')`, which returned `499500`. - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason - Behavior changed: - [ ] No. - [x] Yes. Fixes the link failure and adopts gperftools 2.18.1 allocator and profiling behavior. - Does this need documentation? - [x] No. - [ ] Yes. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label -- 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]
