Date: Sat, 16 Jul 2022 01:12:00 UTC
I need to clear some stuff here. There was a phab review brewing for some time https://reviews.freebsd.org/D35288 Stefan Esser wrote: > I have just committed a port for LLVM 14. It is build tested, but I did > not have time to perform any run tests. > First mistake. The entire WASI toolchain has to be updated, since this is LLVM and no API/ABI compatibility between major versions and all. See the phab chain, where one item actually had to be reverted to a previous upstream revision. > I have copied over the Makefile of the wasi-compile-rt13 port and have > only changed the DISTVERSION to 14.0.6 and regenerated the distinfo file. > >> B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13) >> fix things? > > Yes, if you do not need LLVM 14 for some reason, then staying at 13 > is the easy way to resolve such issues, until version 14 is fully > supported in the ports tree. > Staying at 13 or another LLVM version where the entire chain's version matches is required unless you are okay with unexpected or unexplainable failures. > Please let me know if you find that the wasi-compile-rt14 port does not > work correctly. > > I have preserved the MAINTAINER of wasi-compile-rt13 in this port, but > if there are issues, I'd feel responsible to fix them before handing > the responsibility for further updates over to greg ... ;-) > I will go further: This was not to be committed at all right now, despite appearances. And I say this as one who is still dogfooding the entire WASI-LLVM 14 chain, with www/firefox as the prime consumer, with LTO enabled. Those interested in helping dogfood, identify failure modes, et al with LLVM_DEFAULT=14 can grab the entire diff chain off phab and apply it to your own tree or overlay. But that doesn't address an even bigger issue that's still being figured out: how to make this whole situation, LTO or not, less fragile to deal with. -- Charlie Li …nope, still don't have an exit line.