Bug 260134 - www/firefox: depends on non-existing devel/wasi-compiler-rt90
Summary: www/firefox: depends on non-existing devel/wasi-compiler-rt90
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gecko (Nobody)
Depends on:
Reported: 2021-11-30 09:19 UTC by Trond.Endrestol
Modified: 2021-12-03 16:19 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (gecko)


Note You need to log in before you can comment on or make changes to this bug.
Description Trond.Endrestol 2021-11-30 09:19:50 UTC
Commit f4c07f1834f70e7359c290415aaf47727cda042a, https://cgit.freebsd.org/ports/commit/?id=f4c07f1834f70e7359c290415aaf47727cda042a, added devel/wasi-compiler-rt${LLVM_DEFAULT} as a dependency. LLVM 9.0 is the default version on most architectures and results in www/firefox depending on the non-existing devel/wasi-compiler-rt90. Only devel/wasi-compiler-rt11 and devel/wasi-compiler-rt13 are the viable candidates.

Should we all move to LLVM 11 (or 13)?
Comment 1 Jan Beich freebsd_committer 2021-11-30 09:53:47 UTC
(In reply to Trond.Endrestol from comment #0)
> LLVM 9.0 is the default version on most architectures

No, the default is overriden by Mk/bsd.gecko.mk:

  # Ignore Mk/bsd.default-versions.mk but respect make.conf(5) unless LTO is enabled
  LLVM_DEFAULT=	13 # chase bundled LLVM in lang/rust for LTO

> Should we all move to LLVM 11 (or 13)?

Good luck submitting patches to unbreak other ports. It's a ton of work and per bug 239682 some maintainers may sabotage the effort.
Comment 3 Trond.Endrestol 2021-11-30 11:21:58 UTC
(In reply to Jan Beich from comment #1)
Sort of fixed by enabling LTO. Thank you for the explanation.
Comment 4 Martin Birgmeier 2021-11-30 19:05:57 UTC
Here is a similar issue: In my local /etc/make.conf there is the line


When trying to upgrade www/firefox using portmaster, this results in the following:

[1]# portmaster -a
===>>> Starting check of installed ports for available updates
===>>> Launching child to update firefox-94.0.2_4,2 to firefox-95.0,2

===>>> All >> firefox-94.0.2_4,2 (1/1)

===>>> Currently installed version: firefox-94.0.2_4,2
===>>> Port directory: /net/hal/z/SRC/FreeBSD/ports/MBi/main/www/firefox

===>>> Launching 'make checksum' for www/firefox in background
===>>> Gathering dependency list for www/firefox from ports

===>>> Cannot cd to devel/wasi-compiler-rt12
===>>> Aborting update

===>>> Update for firefox-94.0.2_4,2 failed
===>>> Aborting update

portmaster -a  55.11s user 40.91s system 53% cpu 2:58.32 total

I have trivially created a devel/wasi-compiler-rt12 from devel/wasi-compiler-rt13, which at least gets portmaster going. But it is still pulling in llvm13, seemingly from devel/wasi-libc and devel/wasi-libcxx, with the former specifying LLVM_VERSION?= 13 and the latter DISTVERSION= 13.0.0.

I aborted this trial.

I would like to continue building firefox with llvm12 because pulling in yet another llvm version needs a lot of disk space just for runtime support. llvm12 is mandatory for graphics/mesa-libs, graphics/mesa-dri, and graphics/mesa-gallium-xa (llvm11 is mandatory, but only for build, for emulators/virtualbox-ose).

What would I have to do to make it possible to use llvm12 for compiling firefox? Some changes in devel/wasi-libc and devel/wasi-libcxx, I assume?

-- Martin
Comment 5 Jan Beich freebsd_committer 2021-11-30 21:23:05 UTC
(In reply to Martin Birgmeier from comment #4)

Should work fine after ports 0741c12be4fe.
Comment 6 Martin Birgmeier 2021-12-02 11:26:07 UTC
Thank you for the feedback.

It is already nearly functional but for one thing, namely trying to repeatedly install wasi-compiler-rt12. This seems to be due to the line


in www/firefox/Makefile and the fact that LLVM_VERSION is not set:

[0]# pushd /usr/ports/www/firefox
/usr/ports/www/firefox ~
[0]# make -V LLVM_VERSION


It seems that LLVM_VERSION needs to be set properly in Mk/bsd.gecko.mk for the case when the used llvm is not 13 (I have DEFAULT_VERSIONS+=llvm=12 in my /etc/make.conf). The culprit is most likely the hard-coded lines

LLVM_DEFAULT=   13 # chase bundled LLVM in lang/rust for LTO
LLVM_VERSION=   13.0.0 # keep in sync with devel/wasi-compiler-rt${LLVM_DEFAULT}

It seems that the LLVM_VERSION needs to be set for all the possible (allowed) different version of llvm:

[0]# diff -u Mk/bsd.gecko.mk{.ORIG,}
--- Mk/bsd.gecko.mk.ORIG        2021-12-01 11:14:52.636069000 +0100
+++ Mk/bsd.gecko.mk     2021-12-02 10:55:56.476151000 +0100
@@ -95,7 +95,12 @@
 # Ignore Mk/bsd.default-versions.mk but respect make.conf(5) unless LTO is enabled
 LLVM_DEFAULT=  13 # chase bundled LLVM in lang/rust for LTO
-LLVM_VERSION=  13.0.0 # keep in sync with devel/wasi-compiler-rt${LLVM_DEFAULT}
+# keep the next lines in sync with devel/wasi-compiler-rt${LLVM_DEFAULT}
+.if ${LLVM_DEFAULT} == 13
+LLVM_VERSION=  13.0.0
+.elif ${LLVM_DEFAULT} == 12
+LLVM_VERSION=  12.0.1
 # Require newer Clang than what's in base system unless user opted out
 . if ${CC} == cc && ${CXX} == c++ && exists(/usr/lib/libc++.so)

-- Martin
Comment 7 Christoph Moench-Tegeder freebsd_committer 2021-12-02 21:33:52 UTC
(In reply to Martin Birgmeier from comment #6)

but that needs to be maintained for every llvm version, and you'd need the wasi ports for those llvm versions (also future ones, so this is the cost which keeps on sinking).
Comment 8 Martin Birgmeier 2021-12-03 16:19:59 UTC
Agreed. It is, however, already necessary to keep it in sync for llvm 13.0.0 as shown in bsd.gecko.mk.

For me the major underlying problem is the rather huge cost of needing multiple full installations of llvm for the mesa- and mozilla-derived projects. If we could create a runtime-only part of those llvms that would be a huge improvement.

I think the ports infrastructure would need to grow the ability to create multiple packages from a single port, covering different aspects of that port. For example, recently devel/git has been split in git proper, git-gui, and git-cvs, and as far as I can see this has been done by replicating the full build and then only installing the required parts. If instead these three packages could be created from a single port, the CPU burn could be saved.

Same for llvm-xx: Creating packages for the runtime, actual suite, and documentation comes to mind.

That not (yet?) being available I try to keep the number of llvms necessary in my systems to a minimum by settling on (currently) 12 as the common denominator.

-- Martin