Created attachment 166812 [details] Fix ccc-analyzer Attempting to run scan-build in FreeBSD 10+ is likely to fail because it tries to find gcc which doesn't exist. Changing the ccc-analyzer script to use cc/c++ instead works. I have been experiencing this bug for more than a year in all llvm versions.
Comment on attachment 166812 [details] Fix ccc-analyzer (For some reason I haven't been able to attach patches from chromium lately)
I'm interested to have this fixed as well, but I think it would be safer to use the compilers from the relevant port instead of cc/c++ : in -devel, use clang-devel, in, say 3.6 use clang36, etc...
A commit references this bug: Author: brooks Date: Sat Mar 5 12:35:29 UTC 2016 New revision: 410173 URL: https://svnweb.freebsd.org/changeset/ports/410173 Log: Update to 3.8.0 RC3. Update the version in the clang-format patch. [0] Attempt make ccc-analyzer have a usable default. [1] PR: 207065 [1] Submitted by: kpneal@pobox.com [0] Changes: head/devel/llvm38/Makefile head/devel/llvm38/distinfo head/devel/llvm38/files/clang-patch-tools_clang_tools_clang-format_clang-format.py head/devel/llvm38/files/clang-patch-tools_clang_tools_scan-build_libexec_ccc-analyzer head/devel/llvm38/pkg-plist
(In reply to commit-hook from comment #3) This commit includes a patch which is plausibly upstreamable. Using the "current" version probably isn't something we can make work without patching and I'd rather having something that usually works than have to maintain a patch. Please let me know if this improves the situation. If so I'll get it pushed upstream and apply the patch where required.
For the record, I opened Bug 26568 upstream with the patch. I think it would be nice to have both options: upstream should use cc/c++ and we could have a post-build REINPLACE script to use the clang versions from the port. It is, unfortunately, more work so I would be fine with just the upstreaming for now.
What we have works well enough for now so close this.