[gentoo-user] sys-devel/llvm and LLVM_TARGETS

[gentoo-user] sys-devel/llvm and LLVM_TARGETS

[Dale]

Howdy,

I just noticed this in my updates:

[ebuild     U  ] sys-devel/llvm-13.0.1:13::gentoo [13.0.0:13::gentoo]
USE="binutils-plugin%* libffi ncurses xml -debug -doc -exegesis -libedit
-test -xar -z3 (-gold%*)" ABI_X86="32 (64) (-x32)"
LLVM_TARGETS="(AArch64*) (AMDGPU) (ARM*) (AVR*) (BPF) (Hexagon*)
(Lanai*) (MSP430*) (Mips*) (NVPTX) (PowerPC*) (RISCV*) (Sparc*)
(SystemZ*) (WebAssembly*) (X86) (XCore*) (-ARC) (-CSKY) (-M68k) (-VE)"

The LLVM_TARGETS= part looks odd.  Why do I need ARM, PowerPC, Sparc etc
here?  Is that correct?  The old still installed version doesn't have
those enabled.

Thanks.

Dale

:-)  :-)

Re: [gentoo-user] sys-devel/llvm and LLVM_TARGETS

[Michael]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Saturday, 12 March 2022 01:34:45 GMT Dale wrote:
> Howdy,
> 
> I just noticed this in my updates:
> 
> [ebuild     U  ] sys-devel/llvm-13.0.1:13::gentoo [13.0.0:13::gentoo]
> USE="binutils-plugin%* libffi ncurses xml -debug -doc -exegesis -libedit
> -test -xar -z3 (-gold%*)" ABI_X86="32 (64) (-x32)"
> LLVM_TARGETS="(AArch64*) (AMDGPU) (ARM*) (AVR*) (BPF) (Hexagon*)
> (Lanai*) (MSP430*) (Mips*) (NVPTX) (PowerPC*) (RISCV*) (Sparc*)
> (SystemZ*) (WebAssembly*) (X86) (XCore*) (-ARC) (-CSKY) (-M68k) (-VE)"
> 
> The LLVM_TARGETS= part looks odd.  Why do I need ARM, PowerPC, Sparc etc
> here?  Is that correct?  The old still installed version doesn't have
> those enabled.
> 
> Thanks.
> 
> Dale
> 
> :-)  :-)

You don't need any of these targets in llvm and clang any more than I do.  
There's a bug which explains why these arch targets are now being forced, but 
I can't find it.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] sys-devel/llvm and LLVM_TARGETS

[Dale]

Michael wrote:
> On Saturday, 12 March 2022 01:34:45 GMT Dale wrote:
>> Howdy,
>>
>> I just noticed this in my updates:
>>
>> [ebuild     U  ] sys-devel/llvm-13.0.1:13::gentoo [13.0.0:13::gentoo]
>> USE="binutils-plugin%* libffi ncurses xml -debug -doc -exegesis -libedit
>> -test -xar -z3 (-gold%*)" ABI_X86="32 (64) (-x32)"
>> LLVM_TARGETS="(AArch64*) (AMDGPU) (ARM*) (AVR*) (BPF) (Hexagon*)
>> (Lanai*) (MSP430*) (Mips*) (NVPTX) (PowerPC*) (RISCV*) (Sparc*)
>> (SystemZ*) (WebAssembly*) (X86) (XCore*) (-ARC) (-CSKY) (-M68k) (-VE)"
>>
>> The LLVM_TARGETS= part looks odd.  Why do I need ARM, PowerPC, Sparc etc
>> here?  Is that correct?  The old still installed version doesn't have
>> those enabled.
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-)
> You don't need any of these targets in llvm and clang any more than I do.  
> There's a bug which explains why these arch targets are now being forced, but 
> I can't find it.


That was my thinking when I saw it.  It just looked odd to me.  I found
this bug.

https://bugs.gentoo.org/767700

Is that the one?  It mentions the target but I don't quite understand
the why.  The biggest thing, will this break something if I let it do
it?  I don't have any settings of my own on this package.  It was done
by a dev, who I assume has a good reason for this. 

Dale

:-)  :-) 

Re: [gentoo-user] sys-devel/llvm and LLVM_TARGETS

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

On Saturday, 12 March 2022 08:43:02 GMT Dale wrote:
> Michael wrote:
> > On Saturday, 12 March 2022 01:34:45 GMT Dale wrote:
> >> Howdy,
> >> 
> >> I just noticed this in my updates:
> >> 
> >> [ebuild     U  ] sys-devel/llvm-13.0.1:13::gentoo [13.0.0:13::gentoo]
> >> USE="binutils-plugin%* libffi ncurses xml -debug -doc -exegesis -libedit
> >> -test -xar -z3 (-gold%*)" ABI_X86="32 (64) (-x32)"
> >> LLVM_TARGETS="(AArch64*) (AMDGPU) (ARM*) (AVR*) (BPF) (Hexagon*)
> >> (Lanai*) (MSP430*) (Mips*) (NVPTX) (PowerPC*) (RISCV*) (Sparc*)
> >> (SystemZ*) (WebAssembly*) (X86) (XCore*) (-ARC) (-CSKY) (-M68k) (-VE)"
> >> 
> >> The LLVM_TARGETS= part looks odd.  Why do I need ARM, PowerPC, Sparc etc
> >> here?  Is that correct?  The old still installed version doesn't have
> >> those enabled.
> >> 
> >> Thanks.
> >> 
> >> Dale
> >> 
> >> :-)  :-)
> > 
> > You don't need any of these targets in llvm and clang any more than I do.
> > There's a bug which explains why these arch targets are now being forced,
> > but I can't find it.
> 
> That was my thinking when I saw it.  It just looked odd to me.  I found
> this bug.
> 
> https://bugs.gentoo.org/767700
> 
> Is that the one?  It mentions the target but I don't quite understand
> the why.  The biggest thing, will this break something if I let it do
> it?  I don't have any settings of my own on this package.  It was done
> by a dev, who I assume has a good reason for this. 
> 
> Dale
> 
> :-)  :-) 

That's the one, yes.  As I understand it unless all these targets are set sys-
devel/lld breaks.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Nikos Chantziaras]

On 12/03/2022 10:43, Dale wrote:
> https://bugs.gentoo.org/767700
> 
> Is that the one?  It mentions the target but I don't quite understand
> the why.  The biggest thing, will this break something if I let it do
> it?

No. Unlike GCC, LLVM/Clang is always a cross-compiler. This just enables 
some extra targets. It won't actually affect anything other than perhaps 
the binaries becoming a bit larger.

Re: [gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Wols Lists]

On 12/03/2022 14:22, Nikos Chantziaras wrote:
> On 12/03/2022 10:43, Dale wrote:
>> https://bugs.gentoo.org/767700
>>
>> Is that the one?  It mentions the target but I don't quite understand
>> the why.  The biggest thing, will this break something if I let it do
>> it?
> 
> No. Unlike GCC, LLVM/Clang is always a cross-compiler. This just enables 
> some extra targets. It won't actually affect anything other than perhaps 
> the binaries becoming a bit larger.
> 
> 
I don't fully understand it (and I thought gcc was moving in the same 
direction), but Clang is a front-end, compiling C to "Intermediate 
Representation". LLVM is a middle/back end which calls optimisation 
modules on the IR which finally end up spitting out machine code - for 
whatever definition of machine code floats your boat.

So I guess adding these extra targets just adds another LLVM module that 
just happens to spit out these extra different machine codes.

But that's how LLVM can compile so many different languages - it simply 
converts IR to machine code. There's a whole bunch of different front 
ends, it's just that Clang is the most well known because the world and 
his dog work in C/C++. I believe there's a rust front end, amongst 
others, but it feels like other languages are a bit "second class". Not 
intentionally, but the C guys have so much input into the IR that the 
other languages get swamped, and people take a while to realise that 
what was a good decision for C was not a good decision for languages in 
general, and the other guys are playing catch-up because nobody noticed.

That's not a dig at anybody, it's just life.

I used to follow this on the LLVM mailing list, but that's now migrated 
to discourse, and I think I'm amongst a lot of people who didn't follow 
it ...

Cheers,
Wol

[gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Grant Edwards]

On 2022-03-12, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 12/03/2022 10:43, Dale wrote:
>> https://bugs.gentoo.org/767700
>> 
>> Is that the one?  It mentions the target but I don't quite understand
>> the why.  The biggest thing, will this break something if I let it do
>> it?
>
> No. Unlike GCC, LLVM/Clang is always a cross-compiler.

You can't use LLVM/Clang to compile for the host on which it's
running?

--
Grant

[gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Nikos Chantziaras]

On 12/03/2022 18:03, Grant Edwards wrote:
> On 2022-03-12, Nikos Chantziaras <realnc@gmail.com> wrote:
>> On 12/03/2022 10:43, Dale wrote:
>>> https://bugs.gentoo.org/767700
>>>
>>> Is that the one?  It mentions the target but I don't quite understand
>>> the why.  The biggest thing, will this break something if I let it do
>>> it?
>>
>> No. Unlike GCC, LLVM/Clang is always a cross-compiler.
> 
> You can't use LLVM/Clang to compile for the host on which it's
> running?

Why not?

[gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Grant Edwards]

On 2022-03-12, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 12/03/2022 18:03, Grant Edwards wrote:
>> On 2022-03-12, Nikos Chantziaras <realnc@gmail.com> wrote:
>>> On 12/03/2022 10:43, Dale wrote:
>>>> https://bugs.gentoo.org/767700
>>>>
>>>> Is that the one?  It mentions the target but I don't quite understand
>>>> the why.  The biggest thing, will this break something if I let it do
>>>> it?
>>>
>>> No. Unlike GCC, LLVM/Clang is always a cross-compiler.
>> 
>> You can't use LLVM/Clang to compile for the host on which it's
>> running?
>
> Why not?

Because "LLVM/Clang is always a cross compiler".

A cross compiler is a compiler that compiles for a target
architecture/OS different than that of the host on which it is
running.

Therefore, LLVM/Clang always compiles for a target architecture/OS
different than that of the host on which it is running.

--
Grant

Re: [gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Dale]

Nikos Chantziaras wrote:
> On 12/03/2022 10:43, Dale wrote:
>> https://bugs.gentoo.org/767700
>>
>> Is that the one?  It mentions the target but I don't quite understand
>> the why.  The biggest thing, will this break something if I let it do
>> it?
>
> No. Unlike GCC, LLVM/Clang is always a cross-compiler. This just
> enables some extra targets. It won't actually affect anything other
> than perhaps the binaries becoming a bit larger.
>
>
>


I'm doing this in a chroot so it is recoverable if it was a problem but
now I know it's OK to do on my main install.  I still find it odd but if
it is needed and there is a reason for it, sounds good to me. 

If this were a bad thing tho, this is why it is always good to look at
the output before doing a update.  If this was a serious package that
would cause widespread breakage, one would want to catch this.  I've
sort of read about llvm and clang and I seem to recall things like
Firefox needing them or something.  Even if it did break things, I don't
think it would cause breakage to the point of rendering a system
unbootable or anything.  Still, I check the output of updates for this
reason.  If nothing else, I could have caught the tree in the middle of
a change and missed some important bits. 

Thanks to all for the info. 

Dale

:-)  :-)

Re: [gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Wols Lists]

On 12/03/2022 17:36, Dale wrote:
> I've
> sort of read about llvm and clang and I seem to recall things like
> Firefox needing them or something.

I've just watched firefox emerging (yes I know, paint drying and all 
that :-), and there's loads of Rust code in there.

To the best of my knowledge, gcc can't currently handle Rust, so yes 
LLVM is needed. (Not Clang, because it isn't C :-) (Although Firefox 
probably also uses loads of C, so Clang would be needed for that.)

Cheers,
Wol

Re: [gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Peter Humphrey]

On Sunday, 13 March 2022 08:03:04 GMT Wols Lists wrote:

> To the best of my knowledge, gcc can't currently handle Rust, so yes
> LLVM is needed. (Not Clang, because it isn't C :-) (Although Firefox
> probably also uses loads of C, so Clang would be needed for that.)

And that's why we have dev-lang/rust on hand, no?

-- 
Regards,
Peter.

Re: [gentoo-user] Re: sys-devel/llvm and LLVM_TARGETS

[Dale]

Peter Humphrey wrote:
> On Sunday, 13 March 2022 08:03:04 GMT Wols Lists wrote:
>
>> To the best of my knowledge, gcc can't currently handle Rust, so yes
>> LLVM is needed. (Not Clang, because it isn't C :-) (Although Firefox
>> probably also uses loads of C, so Clang would be needed for that.)
> And that's why we have dev-lang/rust on hand, no?
>


So, it takes rust, gcc, clang and maybe some other stuff to make
Firefox???  Jeez, that sounds complicated.  o_O  Sounds like a recipe
for a soup or something.  ROFL

I might add, I did finish the updates and everything compiled and works
fine.  So, it is safe to have all those options enabled.  Weird but
safe.  ;-)

Dale

:-)  :-)