[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

:-) :-)

[Michael]

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.

[Dale]

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

:-)  :-) 

[Michael]

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

[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.

[Wols Lists]

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

[Grant Edwards]

On 2022-03-12, Nikos Chantziaras <rea...@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

[Dale]

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

:-)  :-)

[Nikos Chantziaras]

Why not?

[Grant Edwards]

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

[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

[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.

[Dale]

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

:-)  :-)