Created attachment 201410 [details] v1 According to llvm.org schedule 8.0.0 is to be released sometime after 2018-02-27. Let's prepare to switch default in Can you add DEFAULT_VERSIONS+=llvm=80 to make.conf(5) and check runtime? Does anyone want to make this happen before actual release? Build logs: - devel/android-tools-simpleperf: https://ptpb.pw/FSvP - devel/ccls: https://ptpb.pw/xObs - devel/cquery: https://ptpb.pw/XQu5 - devel/kdevelop-pg-qt: https://ptpb.pw/1Yr_ - devel/kdevelop: https://ptpb.pw/bXtF - devel/qtcreator: https://ptpb.pw/Lbi1 - devel/rust-bindgen: https://ptpb.pw/09fW - graphics/pcl-pointclouds: https://ptpb.pw/rzjQ - mail/thunderbird: https://ptpb.pw/TH1f - math/mkl-dnn: https://ptpb.pw/g-ZU - net/aluminum: https://ptpb.pw/K6nW - science/agrum: https://ptpb.pw/MLhB - science/erkale: https://ptpb.pw/hBJI - science/lammps: https://ptpb.pw/xJ9P - security/afl: https://ptpb.pw/tKHa - textproc/castxml: https://ptpb.pw/358R - www/cliqz: https://ptpb.pw/hYnv - www/firefox-esr: https://ptpb.pw/wH_J - www/firefox: https://ptpb.pw/u9TD
Created attachment 201412 [details] v1.1 Fixed a typo in textproc/castxml to use llvm80 rather than llvm70: https://ptpb.pw/WzGE
According to https://llvm.org/, the latest LLVM release is 7.0.1, so this PR is premature.
(In reply to Yuri Victorovich from comment #2) ikos says that they will fix compatibility once llvm-8 is released.
https://www.changedetection.com/log/org/llvm/prereleases/releasenotes_log.html
(In reply to Yuri Victorovich from comment #2) > the latest LLVM release is 7.0.1, so this PR is premature. I'm trying to get everyone on board (or off board) by the time devel/llvm80 is updated to the actual release. Some maintainers may need time to evaluate the risk but being on LLVM_DEFAULT train assumes silence after timeout is an agreement. Otherwise, there's a risk of HEAD and 2019Q2 ending up with different LLVM_DEFAULT, complicating maintenance. (In reply to Yuri Victorovich from comment #3) > ikos says that they will fix compatibility once llvm-8 is released. Not quite. According to https://github.com/NASA-SW-VnV/ikos/issues/96#issuecomment-457843971 it doesn't look like ikos upstream plans to keep compatibility with llvm70 much like they haven't with llvm60 or llvm50/llvm40. So, I don't understand why you insist on using LLVM_DEFAULT in the port when it breaks if user specifies non-default value via DEFAULT_VERSIONS+=llvm=NN.
(In reply to Jan Beich from comment #5) > So, I don't understand why you insist on using LLVM_DEFAULT in the port when it breaks if user specifies non-default value via DEFAULT_VERSIONS+=llvm=NN. On one hand, ikos wants llvm-config which the base llvm doesn't support. On the other hand, they require that clang corresponds to the llvm version in use. So there should be a llvm/clang version from ports, and LLVM_DEFAULT looks like a reasonable choice. Their upstream is quite responsive and reasonable, so I don't expect that they would introduce some incompatibility with versions that are currently popular.
Seems ok from the ccls/afl perspective cquery seems ok from a quick test too.
llvm80 is so new that it has not even built yet on any tier-2 arch; in fact, it has only just now built on amd64. Until llvm80 has had a bit more soak-time this push is too agressive IMHO.
(In reply to Mark Linimon from comment #8) http://beefy8.nyi.freebsd.org/data/head-armv6-default/p491221_s343459/logs/errors/llvm80-8.0.0.r1.log
Tier2 cannot block progress: no automation, emulation bugs, real machines oversubscribed and disabled pkg-fallout@ mail. How exactly waiting until after LLVM release would help? (In reply to Mark Linimon from comment #9) > /usr/local/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elflink.c:2920 > /usr/local/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elflink.c:2920 Please, file a separate bug. Builds fine for me: - 11.2 aarch64: https://ptpb.pw/qXhK - 11.2 armv6: https://ptpb.pw/-qOL - 12.0 aarch64: https://ptpb.pw/-UQJ - 12.0 armv6: https://ptpb.pw/P6Nk - 12.0 armv7: https://ptpb.pw/ofVt - 13.0 aarch64: https://ptpb.pw/iaBx - 13.0 armv7: https://ptpb.pw/PirA
Excuse me, by the way, what happens to Mk/Uses/compiler.mk ?
(In reply to Tatsuki Makino from comment #11) Nothing. USES=compiler is mostly nop on aarch64/amd64/armv6/armv7/i386 after FreeBSD < 11.2 EOL. See also bug 230790.
<https://www.reddit.com/r/freebsd/comments/akcx6r/-/ef42hli/> > tl;dr whatever I try, it seems that a build of graphics/mesa-dri requires a build of devel/llvm60 Expected, PEBKAM or bug?
(In reply to Graham Perrin from comment #13) > <https://www.reddit.com/r/freebsd/comments/akcx6r/-/ef42hli/> > > > tl;dr whatever I try, it seems that a build of graphics/mesa-dri requires a build of devel/llvm60 > > Expected, PEBKAM or bug? Expected. mesa-dri doesn't use LLVM_DEFAULT. Set MESA_LLVM_VER=${LLVM_DEFAULT} in your make.conf if you want it to use LLVM_DEFAULT at your own risk.
Tobias: thank you. Moving on … ---- Anyone: is <https://www.reddit.com/comments/ambalm/-/efmrxyw/?context=1> somehow related? From the opening post: > FreeBSD 13.0-CURRENT. No problem with r343308. > After updating the OS (and a jail for poudriere) to r343663, > poudriere lost the ability to configure pkg > > …
cquery seems file. Tried --test-unit and --check.
(In reply to Jan Beich from comment #10) Having these build results would have saved me some time. All I had to go on was the results on the build cluster (which are the only definitive ones). I can, however, verify that llvm80 does now build on powerpc64. I don't have a setup to test on powerpc or powerpcspe.
www/cliqz was built and run without issues using llvm-80.
A commit references this bug: Author: jbeich Date: Wed Mar 20 12:23:31 UTC 2019 New revision: 496337 URL: https://svnweb.freebsd.org/changeset/ports/496337 Log: Switch to devel/llvm80 for DEFAULT_VERSIONS PR: 235215 Changes: head/Mk/bsd.default-versions.mk head/devel/android-tools-simpleperf/Makefile head/devel/ccls/Makefile head/devel/cloudabi-toolchain/Makefile head/devel/cquery/Makefile head/devel/ispc/Makefile head/devel/kdevelop/Makefile head/devel/oclgrind/Makefile head/devel/qtcreator/Makefile head/devel/rust-bindgen/Makefile head/devel/shiboken2/Makefile head/editors/jucipp/Makefile head/graphics/pcl-pointclouds/Makefile head/lang/ponyc/Makefile head/mail/thunderbird/Makefile head/math/mkl-dnn/Makefile head/net/aluminum/Makefile head/science/agrum/Makefile head/science/erkale/Makefile head/science/lammps/Makefile head/security/afl/Makefile head/textproc/castxml/Makefile head/www/cliqz/Makefile head/www/firefox/Makefile head/www/firefox-esr/Makefile
devel/llvm80 had too many RCs putting this in danger of slipping into 2019Q3, so I've landed earlier to get exposure and act on regressions (if any). OTOH, 8.0.0 was tagged a few days ago but upstream hasn't made distfiles available yet (due to release process overhead). Thanks for testing, everyone.
Thanks Nit: 80 is not amongst the possible values at <https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk?annotate=496337&pathrev=496337#l59>
A commit references this bug: Author: jbeich Date: Mon Mar 25 18:09:43 UTC 2019 New revision: 496847 URL: https://svnweb.freebsd.org/changeset/ports/496847 Log: Adjust documented values for LLVM_DEFAULT - Add 80 (current default) but -devel is also possible - Drop 50 as it's being phased out (see bug 236412) PR: 235215 Reported by: Graham Perrin Changes: head/Mk/bsd.default-versions.mk