Description of problem: Any attempt to use tinygo results in an error like this: error: failed to build /usr/lib64/tinygo/src/internal/task/task_asyncify_wasm.S: none of these commands were found in your $PATH: clang-14 Here's how I'm reproducing this issue: Version-Release number of selected component (if applicable): tinygo-0.25.0-2.fc37.x86_64 How reproducible: Always Steps to Reproduce: 1. git clone https://github.com/aquasecurity/trivy.git 2. cd trivy 3. make test Actual results: go generate pkg/module/testdata/analyzer/analyzer.go error: failed to build /usr/lib64/tinygo/src/internal/task/task_asyncify_wasm.S: none of these commands were found in your $PATH: clang-14 pkg/module/testdata/analyzer/analyzer.go:1: running "tinygo": exit status 1 make: *** [Makefile:56: pkg/module/testdata/analyzer/analyzer.wasm] Error 1 Expected results: Successful build Additional info:
Yes, tinygo does not support LLVM 15 yet.
I found where upstream is doing the LLVM 15 work: https://github.com/tinygo-org/tinygo/pull/3189 So what can be done about tinygo in Fedora 37? It's unfortunate that the package is completely nonfunctional.
I can't really do anything; LLVM breaks things with every major release, and it is non-trival to fix. But also, F37 is not out yet, so there's still time. Probably the only thing that could work in the meanwhile is if the clang14 package provided a versioned driver program instead of only the libraries. I re-assigned to that package to see if they think they might do that.
What are the requirements of tinygo with regard to clang/lld and other LLVM binaries? Looking at https://github.com/tinygo-org/tinygo/blob/d984b55311a2acd6c1b14ef6e87ee280e737a925/builder/commands.go#L21-L25, it seems like tinygo would need not just clang-14, but also ld.lld-14, wasm-ld-14 and lldb-14, which would bring up pretty close to maintaining a complete old LLVM toolchain. I'm not familiar with how tinygo works, so it's not entirely obvious to me to what degree these version dependencies are real or just an implementation artifact. Like, does tinygo implement a clang plugin (in which case an exact version match is likely necessary) or does it just use clang as a linker (in which case it probably doesn't actually matter due to bitcode autoupgrade). Same goes for the use of the ld.lld-14 binary -- off the top of my head, I can't think of a reason why one would have to match versions with an LLD binary (as long as it is not older).
I tried to experiment with this myself, but didn't manage to get tinygo to build against the compat packages. How is one supposed to specify the LLVM prefix that the llvm-go bindings use?
tinygo itself is linked with LLVM to do Go->object files, and I think they want to be consistent about it, since they can build fully bundled. I did not know about the bitcode autoupgrade and maybe that is something that will help avoid this. I believe clang is used for CGo only. wasm-lld and ld.lld are used depending on the target, but I'm not entirely certain whether tinygo can't do some linkages itself, in which case we couldn't rely on bitcode autoupgrade. I think that may have been the case historically, but it seems like now everything must go through an external one. (In reply to Nikita Popov from comment #5) > I tried to experiment with this myself, but didn't manage to get tinygo to > build against the compat packages. How is one supposed to specify the LLVM > prefix that the llvm-go bindings use? For this there is a tag that is set, that you can find in %build, which is set from the %clang_llvm_version macro. However, the good news is that this is now unnecessary as upstream has managed to complete support for LLVM 15. I have already backported patches and built it for Rawhide, and am now doing the same for F37, so this should be working properly soon.
FEDORA-2022-05890f50b5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-05890f50b5
FEDORA-2022-05890f50b5 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-05890f50b5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-05890f50b5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-05890f50b5 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.