Bug 235215
| Summary: | Bump LLVM_DEFAULT to 80 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||||
| Component: | Individual Port(s) | Assignee: | Jan Beich <jbeich> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | gecko, grahamperrin, henry.hu.sh, kde, linimon, maciej, santhosh.raju, tatsuki_makino, tobik, yuri, zeising | ||||||
| Priority: | --- | Keywords: | patch, patch-ready | ||||||
| Version: | Latest | Flags: | henry.hu.sh:
maintainer-feedback+
santhosh.raju: maintainer-feedback+ tobik: maintainer-feedback+ yuri: maintainer-feedback+ |
||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Bug Depends on: | 235213 | ||||||||
| Bug Blocks: | 239682 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jan Beich
2019-01-26 12:10:42 UTC
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. (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 |