[llvm-dev] Clang-12 fails build on MacOS

[Steven Wu via llvm-dev]

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>