Summary: | app-emulation/wine-{staging,vanilla}[mingw]: race condition in x86_64-w64-mingw32-strip | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | 12101111 <w12101111> |
Component: | Current packages | Assignee: | Wine Maintainers <wine> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ionen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 351559 | ||
Attachments: | build.log |
Description
12101111
2024-01-08 17:51:14 UTC
(I'll block 'parallel-make' as it's close enough for the tracker purposes.) Created attachment 881675 [details]
build.log
That sounds odd, unless I'm missing something find -exec doesn't call multiple strip at same time and just build an argument list to do afaik sequencial strip calls (several per call, not that strip should be racing with itself). Where would it be racing? Tried that seq loop a few times but I can't reproduce on my glibc system so far (maybe too slow, was on tmpfs fwiw too), and it typically builds fine when I try musl not that I test it much there. (In reply to Ionen Wolkens from comment #3) > Tried that seq loop a few times but I can't reproduce on my glibc system so > far (maybe too slow, was on tmpfs fwiw too), and it typically builds fine > when I try musl not that I test it much there. Sounded like a long shot but fwiw I can't reproduce in a musl chroot either. The seq loop was roughly 2x slower in the musl chroot than glibc though. Either way, not sure what to do with this, technically I don't see anything wrong with the ebuild. *Could* switch to doing only one file per strip(1) call if that helps (maybe a bug in strip(1) if so), albeit that sound like just a bunch of unnecessary forking for an operation that's already relatively slow. |