| 25 Apr 2026 |
 kirillrdy | eg maybe a better fix is not my PR but re trigger build ? | 10:26:02 |
 Randy Eckenrode | One of the dylibs has a bad signature. | 10:32:10 |
| Randy Eckenrode | Darwin needs a hook to fail the build if there are any bad signatures. It won’t fix the underlying problem, but it will at least (hopefully) prevent another mess like this. | 10:33:41 |
| Randy Eckenrode | * | 10:33:56 |
| kirillrdy | how come ffmpeg full doenst have this issue but headless does ? | 10:35:05 |
 K900 | Random coincidence | 10:38:28 |
| kirillrdy | fair enough... | 10:39:50 |
| Randy Eckenrode | Unfortunately, I ran into it when bringing my system back up, so I don’t have my shell history anymore where I fixed it locally. | 10:45:07 |
| kirillrdy | as for fixing issue on master, what is the best approach ? | 10:50:52 |
| Randy Eckenrode | I’m not sure. How far off is the staging-next merge? | 10:51:41 |
| kirillrdy | this is the consequences of recent staging-next merge | 10:52:17 |
| Randy Eckenrode | Oh. ☹️ | 10:52:45 |
| Randy Eckenrode | I wonder if the problem is the way it’s calculating the signature, and it’s a happy accident that both ld64 and ld-prime are effected. | 11:11:02 |
 toonn | Do the linkers use different code to perform signing? | 11:21:17 |
| Randy Eckenrode | We don’t have the source to ld-prime. My hypothesis is that the signing calculation is shared between them. | 11:31:07 |
 emily | this seems hard to reconcile with the state dependence observed by zhaofengli | 11:33:14 |
| emily | though really every data point is hard to reconcile :( | 11:33:33 |
| Randy Eckenrode | Race condition? | 11:34:02 |
| emily | it was "succeeds once on a machine and fails thereafter" IIRC | 11:35:48 |
| emily | or the reverse | 11:35:57 |
| emily | though I don't know if the test setup ruled out the path rewriting from partially present outputs thing | 11:36:20 |
| emily | but it was apparently very consistent | 11:36:39 |
| Randy Eckenrode | https://github.com/reckenrode/ld64/blob/ld64-956.6-nixpkgs/src/ld/OutputFile.cpp#L3967_L3997 | 11:40:46 |
| Randy Eckenrode | It’s calculating the hashes in parallel. Is it safe to use a std::vector like that? | 11:41:22 |
| K900 | As long as it's not pushing anything yes | 11:42:13 |
| Randy Eckenrode | Even on arm64? | 11:44:29 |
| K900 | I don't think it matters? | 11:44:41 |
| K900 | As long as all it's doing is writing to non-overlapping items | 11:45:00 |
| Randy Eckenrode | The other place it calculates the hash is in libcodedirectory. | 11:49:03 |
| Randy Eckenrode | Which ld-prime appears to be using …. | 11:51:23 |
