morningman opened a new issue, #67448: URL: https://github.com/apache/doris/issues/67448
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version master (`ddbaaab1388`), macOS 26.5 arm64, Homebrew clang 20.1.8, `DISABLE_BUILD_UI=ON sh build.sh --fe --be` ### What's Wrong? Linking `bin/kuromoji_build_dict` fails on arm64 because the binary's `__TEXT` segment exceeds the AArch64 ±128 MB branch range: ``` FAILED: [code=1] bin/kuromoji_build_dict ld: fixup error (kind=arm64_b26) at '__ZN8tcmallocL14memalign_pagesEmmbb'+0x1DC from libtcmalloc.a[2](libtcmalloc_la-tcmalloc.o), B/BL out of range (displacement=-135691464, max is +/-128MB), from 0x10816EF18 to 0x100007250 ('___clang_call_terminate') final section layout: __TEXT addr=0x100000000, size=0x008310000 <-- 137 MB __text ... size=0x0059254bc google_malloc addr=0x10816da40, ... malloc_hook addr=0x10816ef3c, ... ``` The linker normally inserts branch islands, but it can only do that inside `__text`. gperftools puts its allocator in the custom sections `google_malloc` and `malloc_hook`, which the linker places *after* `__text`, so a branch from there back to `___clang_call_terminate` at the start of `__TEXT` cannot be relaxed. `doris_be` itself links fine — `ninja doris_be` succeeds. Only `kuromoji_build_dict` is over the limit. The failure also blocks the install step, which hard-fails when the generated dictionary is absent: ``` CMake Error at cmake_install.cmake:96 (message): kuromoji dictionary file .../be/dict/kuromoji/system.bin is missing; build the 'kuromoji_dict' target (stage mecab-ipadic via thirdparty) before packaging. ``` so `output/` is never produced. ### What You Expected? `sh build.sh --be` completes on arm64. ### How to Reproduce? On an Apple Silicon host: ```bash DISABLE_BUILD_UI=ON sh build.sh --fe --be ``` ### Anything Else? `kuromoji_build_dict` is defined under `if (NOT MAKE_TEST)` in `be/CMakeLists.txt` and `kuromoji_dict` is an `ALL` target, so a normal `--be` build links it. `be-ut-mac.yml` runs `./build.sh --be` on `runs-on: macos-15` (arm64) with `-DMAKE_TEST=OFF`, so **that CI job should build this target too** — worth checking whether it is currently green, since my margin was only ~1.4 MB over the limit and could easily differ with another linker version or flag set. Ideas, roughly in order of appeal: - the tool only needs the dictionary builder, not the whole BE; trimming its `target_link_libraries(${DORIS_LINK_LIBS})` down to what `kuromoji_build_dict.cpp` actually uses would take it far under the limit; - link the tool against jemalloc (or no custom allocator) so gperftools' custom sections are not in play; - ship the generated dictionary as a thirdparty artifact instead of building it during the BE build. Found while building BE for #67366; worked around locally by dropping `ALL` from `kuromoji_dict` and skipping the install-time check. ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
