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)?
(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 .if !defined(DEFAULT_VERSIONS) || ! ${DEFAULT_VERSIONS:Mllvm*} || ${PORT_OPTIONS:MLTO} LLVM_DEFAULT= 13 # chase bundled LLVM in lang/rust for LTO .endif > 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.
If you still have trouble building try comparing with the package cluster: http://www.ipv6proxy.net/go.php?u=http://beefy16.nyi.freebsd.org/data/130amd64-default/401d71441a09/logs/firefox-95.0,2.log http://www.ipv6proxy.net/go.php?u=http://beefy15.nyi.freebsd.org/data/130i386-default/401d71441a09/logs/firefox-95.0,2.log http://www.ipv6proxy.net/go.php?u=http://beefy5.nyi.freebsd.org/data/122i386-default/401d71441a09/logs/firefox-95.0,2.log http://www.ipv6proxy.net/go.php?u=http://beefy17.nyi.freebsd.org/data/main-i386-default/p401d71441a09_s0e765d9b08/logs/firefox-95.0,2.log
(In reply to Jan Beich from comment #1) Sort of fixed by enabling LTO. Thank you for the explanation.
Here is a similar issue: In my local /etc/make.conf there is the line DEFAULT_VERSIONS+=llvm=12 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 [1]# 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
(In reply to Martin Birgmeier from comment #4) > DEFAULT_VERSIONS+=llvm=12 Should work fine after ports 0741c12be4fe.
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 ${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libclang_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT} 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 [0]# 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 .if !defined(DEFAULT_VERSIONS) || ! ${DEFAULT_VERSIONS:Mllvm*} || ${PORT_OPTIONS:MLTO} 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} .endif 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 .if !defined(DEFAULT_VERSIONS) || ! ${DEFAULT_VERSIONS:Mllvm*} || ${PORT_OPTIONS:MLTO} 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} +.endif +# 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 .endif # Require newer Clang than what's in base system unless user opted out . if ${CC} == cc && ${CXX} == c++ && exists(/usr/lib/libc++.so) [1]# -- Martin
(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).
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