[llvm-branch-commits] [llvm] release/20.x: [objcopy][MachO] Revert special handling of encryptable binaries (#144058) (PR #144449)

https://github.com/drodriguez approved this pull request. https://github.com/llvm/llvm-project/pull/19 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [llvm-objcopy] Apply encryptable offset to first segment, not section (#130517) (PR #131398)

https://github.com/drodriguez approved this pull request. https://github.com/llvm/llvm-project/pull/131398 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [llvm-objcopy] Apply encryptable offset to first segment, not section (#130517) (PR #131398)

drodriguez wrote: That's why I added "in my experience". I never got a failing binary, but there's yours and another report in the original PR. I never got a failing binary, but I cannot give you a reason why. The `dyld_info` analysis is pretty clear, but it is sometimes more strict than `dyld

[llvm-branch-commits] [llvm] release/20.x: [llvm-objcopy] Apply encryptable offset to first segment, not section (#130517) (PR #131398)

drodriguez wrote: > @drodriguez What do you think about merging this PR to the release branch? @nikic I imagine this is you asking and not a sentient robot? :D I think the fix is safe enough for cherry-picking into the release branch. A couple of people in the issue, PR, and related issues I h