Stefan Esser wrote:
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 just committed a port for LLVM 14. It is build tested, but I did not have time to perform any run tests.
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.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.
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.
OpenPGP_signature
Description: OpenPGP digital signature
