<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Uri<div class=""><br class=""></div><div class="">You misunderstood my message. I never intended to leave it at the broken state for MacPort but I am leaning towards find a correct solution while I suggest some feasible workaround for you. The workaround I provide early will not break M1 mac support since arm64e architecture is experimental and not ABI stable and it is only meant for security researchers to evaluate the implementation.</div><div class=""><br class=""></div><div class="">After some closer look at the build, it seems that the problem only occurs in makefile build, while ninja doesn't even have the race condition since the create_symlink command only ran once. This might be a limitation/bug on the makefile generator, which it lists create_symlink command in both: projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins_arm64_osx.dir/build.make and projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins_arm64e_osx.dir/build.make. I don't know enough about CMake to comment on that. </div><div class=""><br class=""></div><div class="">We also do not have CI system to test makefile support on darwin at all so we might not catch problem of this kind in the future. It might be better to investigate to switch to ninja build to avoid troubles down the road.</div><div class=""><br class=""></div><div class="">Steven<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 18, 2021, at 9:30 PM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">On 7/18/21, 17:01, "Steven Wu" <<a href="mailto:stevenwu@apple.com" class="">stevenwu@apple.com</a>> wrote:<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> Darwin build is a bit different from other build.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">Yes. But it is still defined in what Macports considers “upstream”, aka – you guys. Which is why I’m bringing this issue here.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> I would look for a fix that avoid that race conditions rather than hard code targets.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class="">Adding an explicit separate target via “add_custom_target()” eliminates the race conditions.<o:p class=""></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> Also I don’t know what you mean by giving the workaround a try.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">I mean – incorporate that solution and confirm for yourself that it works.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> The initial workaround I provide is about altering build configuration<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> which is mostly on the user unless you are using the cmake cache in the<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> repo. We also never hit that problem on our side since we always build<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class="">> with ninja and it appears ninja doesn’t schedule the copy close to each other.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class="">Well, with Macports we do not have the luxiry of building with ninja. So, for us it has to stay with CMake.<o:p class=""></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class="">I rather doubt that the workaround you suggested (which kills Apple M1 builds, if I recall correctly) would be acceptable for Macports, whose goal is to successfully build and run for Intel and M1 platforms.<o:p class=""></o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""><span style="" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> <span class="Apple-converted-space"> </span>> On Jul 18, 2021, at 11:32 AM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> <span class="Apple-converted-space"> </span>><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> > It appears that the proposed workaround had been tested and proven to work.<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> ><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> > Which is why I'm asking to give it a try.<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> ><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> > Perhaps doing that would help understanding the root cause too.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> ><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> > Regards,<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> <span class="Apple-converted-space"> </span>> Uri<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> ><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> >> On Jul 18, 2021, at 14:27, Raul Tambre <<a href="mailto:raul@tambre.ee" class="">raul@tambre.ee</a>> wrote:<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> >><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> >> Thanks for the info, however I don't think we still understand the root cause. Why do we end up with two instances trying to create the symlink to the same location?<o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> >><span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 12pt; font-family: Menlo;" class=""> >> Per my thinking different targets end up with separate build directories thus this shouldn't happen. And since the different runtime builds are sub-builds your proposed dependency tracking solution wouldn't work.</div></div></div></blockquote></div><br class=""></div></div></body></html>