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

[Blumenthal, Uri - 0553 - MITLL via llvm-dev]

On 7/18/21, 17:01, "Steven Wu" <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/98eaf22b/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/98eaf22b/attachment.bin>