clang-12 does not build with analyzer

[szhorvat (Szabolcs Horvát)]

The +analyzer variant is no longer on for clang-12, and the port does not build when enabling it manually (port install clang-12 +analyzer). The error:

--->  Applying patches to clang-12
Error: reinplace: couldn't read file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-12/clang-12/work/llvm-project-12.0.0.srcclang/tools/scan-build/libexec/c++-analyzer": no such file or directory
Error: Failed to patch clang-12: reinplace sed(1) failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-12/clang-12/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port clang-12 failed

Full log is attached.

I'll link this here just in case: ​https://trac.macports.org/ticket/62308

[szhorvat (Szabolcs Horvát)]

(If it doesn't make the port too heavy, it would be great to keep the analyzer enabled by default, for the simple reason that building Clang takes a very long time. It's nice to have fully featured binaries. I don't know how big the demand is and how many people are using it, but I'll note that Apple Clang does have the "analyzer" capability.)

[kencu (Ken)]

perhaps missing a "/" here -- all the patches and reinplaces were redone.

llvm-project-12.0.0.srcclang/tools

keep 'em comin'!

[ken-cunningham-webuse]

In 1f4b3803116edd9f57aa69912836a15ec3d53a1c/macports-ports (master):

clang-12: typo in analyzer variant

closes: #63026

[mouse07410 (Mouse)]

I'd like to add my voice in support of returning +analyzer to being the default variant (pre-built binary).

[mouse07410 (Mouse)]

Please re-open this ticket.

The current (as of today) port of clang-12 (a) fails to just pull and install the pre-compiled binaries, and (b) fails to build clang from the sources:

$ sudo port clean clang-12
--->  Cleaning clang-12
$ sudo port install clang-12
--->  Computing dependencies for clang-12
--->  Fetching archive for clang-12
--->  Attempting to fetch clang-12-12.0.1_0+analyzer+libstdcxx.darwin_20.x86_64.tbz2 from https://packages.macports.org/clang-12
--->  Attempting to fetch clang-12-12.0.1_0+analyzer+libstdcxx.darwin_20.x86_64.tbz2 from https://nue.de.packages.macports.org/clang-12
--->  Attempting to fetch clang-12-12.0.1_0+analyzer+libstdcxx.darwin_20.x86_64.tbz2 from http://atl.us.packages.macports.org/clang-12
--->  Fetching distfiles for clang-12
--->  Verifying checksums for clang-12
--->  Extracting clang-12
--->  Applying patches to clang-12
--->  Configuring clang-12
--->  Building clang-12                                  
Error: Failed to build clang-12: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-12/clang-12/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port clang-12 failed
$

Note that this port shouldn't need to recompile locally - I'm not changing its defaults.

It's MacOS 11.4 with Xcode-12.5.1. Full log is attached.

[mouse07410 (Mouse)]

main.log of the clang-12 build

[kencu (Ken)]

there is no need to reopen this ticket, as the analyzer is the default again (although I still hold to the idea that nearly nobody uses it). but that ship sailed...everyone must install perl.

What is happening in your error is a parallel building issue that we have noticed in clang-12 and I have reported upstream. It seems to affect a small % of builds (it never happens to me, for example) but it does happen occasionally. I believe I know the cause.

This time, the arm64 builder hit this issue. I have already forced another build on it. We'll see if it builds next time (in a couple of hours). After all, the arm64 builder built it fine last last time.

Of course, I know I could stop this by disabling parallel building (again -- it was disabled briefly before). Then everyone would build clang-12 with only 1 processor, which would take probably 8 - 10 hours. I was not prepared to tie up the whole buildbot farm for that insanity.

However, if the arm64 builder fails again, I will do that, so the buildbot builds it.

Maybe upstream will fix the bug. I reported it on the llvm-mailing-list, so feel free to go add your voice to the "Me Too!" list if you like. I would open a bug report in their bug reported, but they are just about to shut that bug reported down forever, so .... no point.

As always, we appreciate your support here. If you are in a terrible hurry and don't care to wait, you can temporarily set your build.jobs to 1 in macports.conf, build it, and then delete the line.

Would you say the better option would be to just stop parallel building for everyone, now that it's built on most of the buildbots anyway? Maybe so. I don't know. However, if/when I do that, the next ticket will then be from someone who re-enabled parallel building and found clang-12 built just fine, and in 1 hour instead of 8, and wants the parallel building re-enabled.

[kencu (Ken)]

OK, I disabled parallel building.

​https://github.com/macports/macports-ports/blob/c46123f200f0c300dfcec42c3b7bc83d6b8bd5fb/lang/llvm-12/Portfile#L212

It will take much longer than usual to build clang, but it should finish successfully eventually and the buildbots will eventually have a version you can download.

We can revisit this is in a few months when clang-13 comes out. Perhaps they will have fixed this issue by then.

[mouse07410 (Mouse)]

What is happening in your error is a parallel building issue that we have noticed in clang-12 and I have reported upstream. It seems to affect a small % of builds (it never happens to me, for example) but it does happen occasionally. I believe I know the cause.

First, why does it not just pull the buldbot-created binary? I'd be perfectly happy to not recompile clang-12 locally.

This time, the arm64 builder hit this issue. I have already forced another build on it. We'll see if it builds next time (in a couple of hours). After all, the arm64 builder built it fine last last time.

I'm having the same build failure when I disabled universal builds. :-(

Maybe upstream will fix the bug. I reported it on the llvm-mailing-list, so feel free to go add your voice to the "Me Too!" list if you like. I would open a bug report in their bug reported, but they are just about to shut that bug reported down forever, so .... no point.

Yeah... Let's hope. Yes, I'll post to llvm-dev, maybe it would add some weight...

As always, we appreciate your support here. If you are in a terrible hurry and don't care to wait, you can temporarily set your build.jobs to 1 in macports.conf, build it, and then delete the line

Well... I like running the latest stable compilers, but not in that much of a hurry. Let me see, and probably try single-threaded build.

Would you say the better option would be to just stop parallel building for everyone, now that it's built on most of the buildbots anyway?

No, probably not - if it builds OK for pretty much everyoney else, including build-bots. To repeat myself - I don't really want to build it myself either. Macports for some reason does not pull the binaries and insists on doing local recompile, which I would prefer to avoid.

We can revisit this is in a few months when clang-13 comes out. Perhaps they will have fixed this issue by then.

If I need to wait a few months for a working "latest" clang - so be it, it's not the end of the world. I'm using clang-11 now for most of my things...

Will try the port again, and report here.

[kencu (Ken)]

both the BigSur buildbots failed, so I disabled parallel building.

The arm buildbot then suceeded of course; the Intel builbot is still waiting to rebuild it it appears.

[mouse07410 (Mouse)]

OK, reporting. With your ​​https://github.com/macports/macports-ports/blob/c46123f200f0c300dfcec42c3b7bc83d6b8bd5fb/lang/llvm-12/Portfile#L212 fix, both of my x86_64 Big Sur 11.4 machines built clang-12 fine. It took approximately 5 hours on each.

Let's hope clang-13 will fix the issue upstream...

[mouse07410 (Mouse)]

If you follow the llvm list, you saw the request to file a bug report at ​https://bugs.llvm.org

Can you do that for x86_64-only build? I don't think I preserved the complete log from the build when I disabled Universal...

[kencu (Ken)]

Last I looked a couple of days ago, there was no response, so if there is one now, must have just showed up.

I don't subscribe to the llvm list as there are dozens of messages a day.

The LLVM bug reporter is being shut down as we speak, in favour of a new plan, and they are trying to move all the bugs over to the new system. So opening new bugs there might not be as effective as usual.

Let me see what the status of the new bug reporter is to see where they are in the move.

[kencu (Ken)]

In my very specific message a few weeks ago I gave them what I believe is the proper solution, rather than the 'disabling archs' workaround that was suggested to you (which we are not going to do).

[mouse07410 (Mouse)]

In my very specific message a few weeks ago I gave them what I believe is the proper solution, rather than the 'disabling archs' workaround that was suggested to you (which we are not going to do).

Perhaps you could post that message here, or get it to me some other way, so I can post it on the llvm list again to, at the very least, try to stir a discussion?

[kencu (Ken)]

MacPorts ticket for this issue is #63085 rather than here, and all the needed information including links to relevant cmake information and to my llvm-lists message that explains the problem is all in that ticket.

Let's stop posting in this ticket about this issue.