Bug 235215 - Bump LLVM_DEFAULT to 80
Summary: Bump LLVM_DEFAULT to 80
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
URL:
Keywords: patch, patch-ready
Depends on: 235213
Blocks:
  Show dependency treegraph
 
Reported: 2019-01-26 12:10 UTC by Jan Beich
Modified: 2019-03-29 15:34 UTC (History)
11 users (show)

See Also:
jbeich: maintainer-feedback? (gecko)
henry.hu.sh: maintainer-feedback+
jbeich: maintainer-feedback? (kde)
santhosh.raju: maintainer-feedback+
tobik: maintainer-feedback+
yuri: maintainer-feedback+


Attachments
v1 (8.31 KB, patch)
2019-01-26 12:10 UTC, Jan Beich
no flags Details | Diff
v1.1 (8.31 KB, patch)
2019-01-26 12:21 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2019-01-26 12:10:42 UTC
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
Comment 1 Jan Beich freebsd_committer 2019-01-26 12:21:40 UTC
Created attachment 201412 [details]
v1.1

Fixed a typo in textproc/castxml to use llvm80 rather than llvm70: https://ptpb.pw/WzGE
Comment 2 Yuri Victorovich freebsd_committer 2019-01-26 16:23:38 UTC
According to https://llvm.org/, the latest LLVM release is 7.0.1, so this PR is premature.
Comment 3 Yuri Victorovich freebsd_committer 2019-01-26 16:24:39 UTC
(In reply to Yuri Victorovich from comment #2)

ikos says that they will fix compatibility once llvm-8 is released.
Comment 5 Jan Beich freebsd_committer 2019-01-26 21:37:15 UTC
(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.
Comment 6 Yuri Victorovich freebsd_committer 2019-01-26 21:46:27 UTC
(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.
Comment 7 Tobias Kortkamp freebsd_committer 2019-01-27 08:13:19 UTC
Seems ok from the ccls/afl perspective

cquery seems ok from a quick test too.
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2019-01-27 08:14:38 UTC
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.
Comment 10 Jan Beich freebsd_committer 2019-01-27 08:50:57 UTC
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
Comment 11 Tatsuki Makino 2019-01-27 22:57:55 UTC
Excuse me, by the way, what happens to Mk/Uses/compiler.mk ?
Comment 12 Jan Beich freebsd_committer 2019-01-28 05:22:29 UTC
(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.
Comment 13 Graham Perrin 2019-01-28 08:03:48 UTC
<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?
Comment 14 Tobias Kortkamp freebsd_committer 2019-01-28 08:06:50 UTC
(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.
Comment 15 Graham Perrin 2019-02-03 02:30:47 UTC
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
> 
> …
Comment 16 Henry Hu 2019-02-03 19:14:04 UTC
cquery seems file. Tried --test-unit and --check.
Comment 17 Mark Linimon freebsd_committer freebsd_triage 2019-02-04 11:19:08 UTC
(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.
Comment 18 Santhosh Raju 2019-02-20 08:20:07 UTC
www/cliqz was built and run without issues using llvm-80.
Comment 19 commit-hook freebsd_committer 2019-03-20 12:24:31 UTC
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
Comment 20 Jan Beich freebsd_committer 2019-03-20 12:25:09 UTC
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.
Comment 21 Graham Perrin 2019-03-23 21:31:57 UTC
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>
Comment 22 commit-hook freebsd_committer 2019-03-25 18:10:04 UTC
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