Hi Uri 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. 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. 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. Steven> On Jul 18, 2021, at 9:30 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote: > > On 7/18/21, 17:01, "Steven Wu" <stevenwu at apple.com <mailto:stevenwu at apple.com>> wrote: > > > Darwin build is a bit different from other build. > > Yes. But it is still defined in what Macports considers “upstream”, aka – you guys. Which is why I’m bringing this issue here. > > > I would look for a fix that avoid that race conditions rather than hard code targets. > > Adding an explicit separate target via “add_custom_target()” eliminates the race conditions. > > > Also I don’t know what you mean by giving the workaround a try. > > I mean – incorporate that solution and confirm for yourself that it works. > > > The initial workaround I provide is about altering build configuration > > which is mostly on the user unless you are using the cmake cache in the > > repo. We also never hit that problem on our side since we always build > > with ninja and it appears ninja doesn’t schedule the copy close to each other. > > Well, with Macports we do not have the luxiry of building with ninja. So, for us it has to stay with CMake. > > 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. > > > > On Jul 18, 2021, at 11:32 AM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote: > > > > It appears that the proposed workaround had been tested and proven to work. > > > > Which is why I'm asking to give it a try. > > > > Perhaps doing that would help understanding the root cause too. > > > > Regards, > > Uri > > > >> On Jul 18, 2021, at 14:27, Raul Tambre <raul at tambre.ee> wrote: > >> > >> 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? > >> > >> 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.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210719/3713a3bf/attachment.html>
Blumenthal, Uri - 0553 - MITLL via llvm-dev
2021-Jul-19 18:29 UTC
[llvm-dev] Clang-12 fails build on MacOS
You misunderstood my message. My apologies, and thank you for clarifying. I never intended to leave it at the broken state for MacPort but I am leaning towards finding a correct solution while I suggest some feasible workaround for you. Thank you! But it seems that adding a custom target in CMake via add_custom_target() would fix the MacPort version, while staying harmless on the other platforms? Or am I missing something…? 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. It looks like Macports team would prefer a different workaround. 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. Yes, I concur (though the Macports maintainers of the Clang port are the “authoritative” source here, not me 😉). 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. Neither do I. But it looks like that bug (or limitation? Whatever it might be…) gets side-stepped by add_custom_target(). Which is why I’m advocating for applying that workaround now, until (and if!) a better one arrives. 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. Understood. Unfortunately, moving to ninja is not my call at all. ☹ I suspect that the maintainers are concerned that there already are many dependencies (e.g., full Perl) required to build Clang. Not sure if they’d be happy about pulling ninja in as well – plus, ninja may require other python packages installed to run the build…? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210719/20f8082f/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210719/20f8082f/attachment-0001.bin>