[6.0.0 Release] The final tag is in

Dear testers,

The final version of 6.0.0 has just been tagged from the branch after
r326550. It has the same contents as -rc3 modulo release notes and one
small x86 fix (r326393).

Please build the final binaries and upload to the sftp.

For those following along: this means llvm-6.0.0 is complete, but it
will take a few days to get all the tarballs ready and published on
the web page. I will send the announcement once everything is ready.

Many thanks to everyone for your hard work!


FYI, RPMs for CentOS6 are here;


20.9 MB clang-6.0.0-1.el6.x86_64.rpm
689 KB clang-format-6.0.0-1.el6.x86_64.rpm
500 KB libcxx-6.0.0-1.el6.x86_64.rpm
480 KB libcxx-devel-6.0.0-1.el6.noarch.rpm
122 KB libcxxabi-6.0.0-1.el6.x86_64.rpm
12.8 MB lld-6.0.0-1.el6.x86_64.rpm

I will propose tweaks for CPack, in near future.


Built, tested and uploaded:

SHA256 (clang+llvm-6.0.0-amd64-unknown-freebsd-10.tar.xz) = fee8352f5dee2e38fa2bb80ab0b5ef9efef578cbc6892e5c724a1187498119b7
SHA256 (clang+llvm-6.0.0-i386-unknown-freebsd-10.tar.xz) = 13414a66b680760171e04f32071396eb6e5a179ff0b5a067d48c4b23744840f1

On amd64-freebsd10 there were 523 unexpected test failures (down from 526 at rc3):

  Expected Passes : 45388
  Passes With Retry : 1
  Expected Failures : 185
  Unsupported Tests : 2937
  Unexpected Passes : 1
  Unexpected Failures: 523

On i386-freebsd10 there were 246 unexpected test failures (down from 250 at rc3):

  Expected Passes : 44232
  Expected Failures : 194
  Unsupported Tests : 1954
  Unexpected Passes : 1
  Unexpected Failures: 246


Uploaded ubuntu, SLES11, SLES12 binaries.

4907dbd37f4e5265a2f1252d9d7b5e5b0a9c0ec1 clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz
360b26fcd9eafe5ca9c4baa89c38339bc587c094 clang+llvm-6.0.0-x86_64-linux-sles11.3.tar.xz
ce525cf949ef86409bc3f4f492035225989eecfd clang+llvm-6.0.0-x86_64-linux-sles12.2.tar.xz

It was just brought to my attention that the RPATH configuration isn’t uniform among the libraries produced by the release. Some use $ORIGIN…/lib/ and others have none. Is this by design? It seems like it might be ideal for all of them to be configured the same way. If that makes sense I’ll create a corresponding feature request.

$ for f in ./clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/lib*.so*; do echo $f; readelf -d $f|grep RUNPATH; done
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
readelf: Error: ./clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04/lib/libc++.so: Failed to read file header
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/…/lib]

From what I can see all of the libraries without RPATH are runtime libraries that are used by binaries compiled with Clang. I think they don't have a dependency on other libraries in that directory, so what would be the advantage of having RPATH set on them?


Isn’t libc++.so dependent on libc++abi.so?

libc++.so should be a linker script that automatically pulls in libc++abi (see "Failed to read file header" in your output). And IIRC libc++abi is only one possible implementation that may be used by libc++, but I'm no expert here...

Ok, yes, you’re right – thanks for clarification.

Hi Hans,

I've uploaded the Darwin x86_64 package:

$ shasum -a 256 clang+llvm-6.0.0-x86_64-apple-darwin.tar.xz
0ef8e99e9c9b262a53ab8f2821e2391d041615dd3f3ff36fdf5370916b0f4268 clang+llvm-6.0.0-x86_64-apple-darwin.tar.xz



$ sha1sum LLVM-6.0.0-win*.exe
c6a02b7a6e409a0ea36f387ada76064d72d83cb0 LLVM-6.0.0-win32.exe
fea55c689de7c7c8939831b41926bdec9144a432 LLVM-6.0.0-win64.exe

They were built with the attached batch file.

build_llvm_600.bat|attachment (4.65 KB)


Hi Hans,

Looks ok here. I've uploaded the binaries.

SHA256(clang+llvm-6.0.0-mipsel-linux-gnu.tar.xz)= 5ff062f4838ac51a3500383faeb0731440f1c4473bf892258314a49cbaa66e61
SHA256(clang+llvm-6.0.0-mips-linux-gnu.tar.xz)= 39820007ef6b2e3a4d05ec15feb477ce6e4e6e90180d00326e6ab9982ed8fe82
SHA256(clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz)= ff55cd0bdd0b67e22d1feee2e4c84dedc3bb053401330b64c7f6ac18e88a71f1



ARM & AArch64 also up and ready:


Hey Brian,

I saw your upload for Ubuntu 14.04 bt found myself in need for deploying binaries to run on Ubuntu 16.04, are we expected the 14.04 one to “just work”?
Should we mention it on the download page?



Sorry, I didn’t get a chance to build it for 16.04, my 16.04 machine was down at the time. I think the 14.04 binaries will likely work but I will go ahead and rebuild it for 16.04 this week.


Sorry for the delay – ran into some challenges getting a 16.04 system running. After some experimentation with docker I was able to reproduce it.

Uploaded 16.04 as clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

801555304a0c2bc771277818a15a512c24ad1be3 clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

No need to apologize, thanks a lot Brian!

Thanks! I've added this to the download page along with Tom's Fedora
binaries that he uploaded yesterday. It might take a little while for
the change to propagate to the CDN.