On 29/10/2022 22.35, Piotr Karbowski wrote:
On 29/10/2022 21.01, Matt Turner wrote:
lld isn't a dependency of llvm; it's the same reason why llvm:N
doesn't depend on clang:N.
That's fair. Still a bit of a bummer that we cannot guarantee a
frictionless support for clang-based kernels, in a
On 29/10/2022 21.01, Matt Turner wrote:
lld isn't a dependency of llvm; it's the same reason why llvm:N
doesn't depend on clang:N.
That's fair. Still a bit of a bummer that we cannot guarantee a
frictionless support for clang-based kernels, in a sense that your
system could pull new update
On Sat, Oct 29, 2022 at 12:53 PM Piotr Karbowski wrote:
>
> On 29/10/2022 18.22, Matt Turner wrote:
> > Have you seen these commits?
>
> I did not, thanks. Seems like the solution. Is there a reason why llvm:N
> do not pull in lld:N in that case?
lld isn't a dependency of llvm; it's the same
On 29/10/2022 18.22, Matt Turner wrote:
Have you seen these commits?
I did not, thanks. Seems like the solution. Is there a reason why llvm:N
do not pull in lld:N in that case?
-- Piotr.
On Sat, Oct 29, 2022 at 12:01 PM Piotr Karbowski wrote:
> The state for this very moment is that we can have many versions of llvm
> around, however we can at most have only one ld.lld installed. Usually
> matching the lowest version of clang installed.
Have you seen these commits?
commit
Hi,
The state for this very moment is that we can have many versions of llvm
around, however we can at most have only one ld.lld installed. Usually
matching the lowest version of clang installed.
THis leads to build failures if one attempts to build some (but not all)
software, Linux kernel
