morningman opened a new pull request, #67564:
URL: https://github.com/apache/doris/pull/67564
### What problem does this PR solve?
Problem Summary:
Every branch-4.1 PR that touches `thirdparty/` fails `Build Third Party
Libraries (macOS-arm64)` after two to three minutes, inside
`download-thirdparty.sh`, long before anything is compiled:
```
patching file 'src/dwarf/Gfind_proc_info-lsb.c'
2 out of 2 hunks failed--saving rejects to
'src/dwarf/Gfind_proc_info-lsb.c.rej'
##[error]Process completed with exit code 1.
```
| PR | base | `Build Third Party Libraries (macOS-arm64)` |
|---|---|---|
| #67378 | branch-4.1 | fail, 5m18s — these hunks |
| #67356 | branch-4.1 | fail, 3m11s — these hunks |
| #67523 | branch-4.1 | fail, 2m43s — these hunks |
| #67554 | branch-4.1 | fail, 2m43s — these hunks |
| **#67535** — same change as #67523 | **master** | **pass, 2h26m full
build** |
The last row is the point: the same content passes on master and dies in the
patch step on branch-4.1.
**Root cause.** `thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch`
is corrupt on this branch. It arrived that way in `4439e6f6b46` (the backport
of #64093) and does not match the file master carries (`dc70115a432`) — even
though both branches pin the same libunwind 1.6.2 with the same md5 and run
byte-identical patching code in `download-thirdparty.sh`.
In master's copy the blank lines around the change are **context** lines,
each a line holding a single space. In this branch's copy they are **deletion**
lines (`-` with nothing after it), with the hunk headers renumbered to match
that reading (`@@ -46,3 +46,8 @@` instead of `@@ -47,6 +47,14 @@`, `@@ -805,5
+810,6 @@` instead of `@@ -804,7 +812,10 @@`) and the trailing context dropped.
That is what a trailing-whitespace strip followed by a hand repair leaves
behind. The patch now asks `patch(1)` to delete blank lines that the real
source does not have at those offsets.
**Why only macOS.** GNU patch on the Linux runner recovers from it — `Hunk
#1 succeeded at 12 with fuzz 1` — and the Linux job passes, which is why this
went unnoticed for a week. The macOS runner's `patch` rejects both hunks and
`download-thirdparty.sh` exits 1.
**Fix.** Take master's copy verbatim. One file, nothing else.
### Release note
None
### Check List (For Author)
- Test
- [ ] Regression test
- [ ] Unit Test
- [x] Manual test (add detailed scripts or steps below)
Verified against the pinned tarball (`libunwind-1.6.2.tar.gz`, md5
`f625b6a98ac1976116c71708a73dc44a`) with the same patch implementation the
runner uses (`patch 2.0-12u11-Apple`), on two pristine copies of the extracted
source:
| patch file | exit | result |
|---|---|---|
| this branch's current file | **1** | `2 out of 2 hunks failed` —
byte-identical to the CI message |
| this PR's file | **0** | applies cleanly, no `.rej` |
After applying, the weak declaration and the fork land where
`be/src/common/phdr_cache.cpp` expects them:
```
54:extern int doris_unwind_iterate_phdr (int (*callback) (struct
dl_phdr_info *, size_t, void *),
55: void *data, unw_word_t ip)
__attribute__ ((weak));
...
815: if (doris_unwind_iterate_phdr)
816: ret = doris_unwind_iterate_phdr (dwarf_callback, &cb_data, ip);
817: else
818: ret = dl_iterate_phdr (dwarf_callback, &cb_data);
```
This branch does define that symbol (`be/src/common/phdr_cache.cpp:249`), so
the fix restores the intended behaviour rather than being a no-op. Linux builds
were already getting it via fuzz, so no behaviour changes there.
- Behavior changed:
- [x] No. Linux already applied this patch (with fuzz); this only makes
the macOS thirdparty build stop failing.
- Does this need documentation?
- [x] No.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01DzUYFcGHQH3bnLGCjpncVj
--
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]
