llvm dev - Jul 2021 - Clang-12 fails build on MacOS

> On Jul 19, 2021, at 11:29 AM, Blumenthal, Uri - 0553 - MITLL <uri at
ll.mit.edu> wrote:
> 
> 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…?
Can you propose a patch for that? I will happily review and commit it for you.

Steven
>  
> 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/caf623cc/attachment.html>

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…?

 

Can you propose a patch for that? I will happily review and commit it for you.

 

Let me converse with Ken, who has the honor of suggesting this fix, and reply. 

 

Offhand, it seems that somewhere (immediately) after this line 

https://github.com/llvm/llvm-project/blob/4c92e31dd0f1bd152eda883af20ff7fbcaa14945/compiler-rt/lib/builtins/CMakeLists.txt#L537

you’d need (something like)

 

add_custom_target(compiler-rt-asm ALL DEPENDS ${helper_asm})

 

Thanks!

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210719/6c5de535/attachment.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/6c5de535/attachment.bin>