The error is basically: :info:build CMake Error: failed to create symbolic link '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-12/clang-12/work/build/projects/compiler-rt/lib/builtins/outline_atomic_helpers.dir/outline_atomic_ldadd2_1.S': file already exists Looks like this is caused by https://reviews.llvm.org/D93178 <https://reviews.llvm.org/D93178>. It seems that when you build multiple arm64 slice (in this case, arm64 and arm64e), the LSE builtin will be generated twice. In the rare case that when two same `cmake -E create_symlink` running at the same time, you get that error. Before the change, it was compiling using clang so you don't get this weird race condition. You can probably workaround by manually set `DARWIN_osx_BUILTIN_ARCHS` to remove `arm64e` since you don't really need that. At the meantime, can you file a bug report to bugs.llvm.org <http://bugs.llvm.org/>? Steven> On Jul 16, 2021, at 12:24 PM, Blumenthal, Uri - 0553 - MITLL via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It seems there’s a problem with parallel builds, but I don’t really know the cause of the problem. You can see the screen log and the complete build log here: https://trac.macports.org/ticket/63026#comment:5 <https://trac.macports.org/ticket/63026#comment:5> > > iMac Pro (Intel Core i9, 10 cores), MacOS Big Sur 11.4, Xcode-12.5.1, clang-12.0.1. > > It would be great if this problem is resolved. > > Thanks! > -- > Regards, > Uri Blumenthal Voice: (781) 981-1638 > Secure Resilient Systems and Technologies Cell: (339) 223-5363 > MIT Lincoln Laboratory > 244 Wood Street, Lexington, MA 02420-9108 > > Web: https://www.ll.mit.edu/biographies/uri-blumenthal <https://www.ll.mit.edu/biographies/uri-blumenthal> > Root CA: https://www.ll.mit.edu/llrca2.pem <https://www.ll.mit.edu/llrca2.pem> > > There are two ways to design a system. One is to make is so simple there are obviously no deficiencies. > The other is to make it so complex there are no obvious deficiencies. > - C. A. R. Hoare > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210716/e8a2796c/attachment.html>
Blumenthal, Uri - 0553 - MITLL via llvm-dev
2021-Jul-16 20:58 UTC
[llvm-dev] Clang-12 fails build on MacOS
The error is basically:
:info:build CMake Error: failed to create symbolic link
'/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-12/clang-12/work/build/projects/compiler-rt/lib/builtins/outline_atomic_helpers.dir/outline_atomic_ldadd2_1.S':
file already exists
Understood, thanks!
Looks like this is caused by https://reviews.llvm.org/D93178. It seems that when
you build multiple arm64 slice (in this case, arm64 and arm64e), the LSE builtin
will be generated twice. In the rare case that when two same `cmake -E
create_symlink` running at the same time, you get that error. Before the change,
it was compiling using clang so you don't get this weird race condition.
The problem is – even when I am forcing Macports to not build “fat” binaries
(aka, limit the build to x86_64 only), I’m still getting an error.
You can probably workaround by manually set `DARWIN_osx_BUILTIN_ARCHS` to remove
`arm64e` since you don't really need that.
Please see above. I don’t think it helped – at least when I’m building via
Macports (where what I’m doing should be the same or equivalent to what you’re
suggesting). :-(
At the meantime, can you file a bug report to bugs.llvm.org?
I was told this reporting mechanism is going away…?
But sure, if you think it makes sense, I’ll file a report there.
Thanks!
On Jul 16, 2021, at 12:24 PM, Blumenthal, Uri - 0553 - MITLL via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
It seems there’s a problem with parallel builds, but I don’t really know the
cause of the problem. You can see the screen log and the complete build log
here: https://trac.macports.org/ticket/63026#comment:5
iMac Pro (Intel Core i9, 10 cores), MacOS Big Sur 11.4, Xcode-12.5.1,
clang-12.0.1.
It would be great if this problem is resolved.
Thanks!
--
Regards,
Uri Blumenthal Voice: (781) 981-1638
Secure Resilient Systems and Technologies Cell: (339) 223-5363
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
Web: https://www.ll.mit.edu/biographies/uri-blumenthal
Root CA: https://www.ll.mit.edu/llrca2.pem
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210716/dd0c89c9/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/20210716/dd0c89c9/attachment.bin>
How does the build end up with two commands symlinking to the same location? Different targets through `LLVM_RUNTIME_TARGETS` should end up with separate build directories. arm64 and arm64e are different targets, right? Creating the symlinks during CMake configuration should be possible as an alternative.
Blumenthal, Uri - 0553 - MITLL via llvm-dev
2021-Jul-18 17:13 UTC
[llvm-dev] Clang-12 fails build on MacOS
On 7/17/21, 09:11, "Raul Tambre" <raul at tambre.ee> wrote:> How does the build end up with two commands symlinking to the same location?> Different targets through `LLVM_RUNTIME_TARGETS` should end up with separate> build directories. arm64 and arm64e are different targets, right?>> Creating the symlinks during CMake configuration should be possible as an> alternative.Ken researched this problem, discovered its cause and suggested a workaround: It appears that when running a custom_command, cmake does not use dependency tracking and collisions can happen. "Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one)." https://cmake.org/cmake/help/v3.19/command/add_custom_command.html The workaround is to add_custom_target a dependency on the output of the custom command. https://gist.github.com/socantre/7ee63133a0a3a08f3990 It would be great if LLVM maintainers incorporated this workaround, or, at the very least, gave it a try. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210718/4da9fa2e/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/20210718/4da9fa2e/attachment.bin>