[gentoo-dev] Clang/LLVM profile

[gentoo-dev] Clang/LLVM profile

[2b57]

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

Hello all,

I'm in the middle of developing a proof-of-concept "native" Clang/LLVM profile – such, that stage3 built using this profile will not even contain GCC and binutils. Why? Well, because Clang is in pretty good shape lately, you can compile kernel and elfutils even. Also just for fun!

The approach I've decided to take is to create virtual/toolchain and virtual/binutils packages with RDEPEND attributes set to gcc || clang and binutils || llvm. I've reached a point where modifications to ::gentoo/scripts/bootstrap.sh are needed, and currently I've solved it with making an OverlayFS overlay, which combines both ::gentoo repo and my custom script. General idea is that once LLVM toolchain is in place (stage1), custom profile for stage2 masks gcc/binutils and virtuals get resolved by LLVM stuff. However, that is not the case; something goes wrong and it seems that binutils package is deeply embedded somewhere else...

Anyway, I'd appreciate any feedback and suggestions, since I'm sure I'm not the only one interested in this topic.

Grab the src here: https://github.com/2b57/toolchain-clang

[-- Attachment #2: Type: text/html, Size: 1293 bytes --]

[gentoo-dev] Re: Clang/LLVM profile

[2b57]

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

Sorry all, it seems that I've confused the lists. I'll forward this to user

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 29th, 2021 at 2:42 AM, 2b57 <2b57@protonmail.com> wrote:

> Hello all,
>
> I'm in the middle of developing a proof-of-concept "native" Clang/LLVM profile – such, that stage3 built using this profile will not even contain GCC and binutils. Why? Well, because Clang is in pretty good shape lately, you can compile kernel and elfutils even. Also just for fun!
>
> The approach I've decided to take is to create virtual/toolchain and virtual/binutils packages with RDEPEND attributes set to gcc || clang and binutils || llvm. I've reached a point where modifications to ::gentoo/scripts/bootstrap.sh are needed, and currently I've solved it with making an OverlayFS overlay, which combines both ::gentoo repo and my custom script. General idea is that once LLVM toolchain is in place (stage1), custom profile for stage2 masks gcc/binutils and virtuals get resolved by LLVM stuff. However, that is not the case; something goes wrong and it seems that binutils package is deeply embedded somewhere else...
>
> Anyway, I'd appreciate any feedback and suggestions, since I'm sure I'm not the only one interested in this topic.
>
> Grab the src here: https://github.com/2b57/toolchain-clang

[-- Attachment #2: Type: text/html, Size: 1761 bytes --]

Re: [gentoo-dev] Clang/LLVM profile

[Sam James]

[-- Attachment #1.1: Type: text/plain, Size: 2346 bytes --]



> On 29 Nov 2021, at 01:45, 2b57 <2b57@protonmail.com> wrote:
> 
> Sorry all, it seems that I've confused the lists. I'll forward this to user
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, November 29th, 2021 at 2:42 AM, 2b57 <2b57@protonmail.com> wrote:
>> Hello all,
>> 
>> I'm in the middle of developing a proof-of-concept "native" Clang/LLVM profile – such, that stage3 built using this profile will not even contain GCC and binutils. Why? Well, because Clang is in pretty good shape lately, you can compile kernel and elfutils even. Also just for fun!
>> 
>> The approach I've decided to take is to create virtual/toolchain and virtual/binutils packages with RDEPEND attributes set to gcc || clang and binutils || llvm. I've reached a point where modifications to ::gentoo/scripts/bootstrap.sh are needed, and currently I've solved it with making an OverlayFS overlay, which combines both ::gentoo repo and my custom script. General idea is that once LLVM toolchain is in place (stage1), custom profile for stage2 masks gcc/binutils and virtuals get resolved by LLVM stuff. However, that is not the case; something goes wrong and it seems that binutils package is deeply embedded somewhere else...
>> 
>> Anyway, I'd appreciate any feedback and suggestions, since I'm sure I'm not the only one interested in this topic.
>> 
>> Grab the src here: https://github.com/2b57/toolchain-clang <https://github.com/2b57/toolchain-clang>
> 

Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us are quite interested in this.

That said, a few notes:
- I'm not sure why you would need virtual/toolchain or virtual/binutils unless it's just for usage within bootstrapping scripts? Seems more like you could just remove gcc from @system and such?

- _personally_, I'd prefer to do experimentation using libstdc++ from GCC and try libcxx later on as a fair amount of things still fail to build with LLVM's libcxx. But that doesn't mean others have the same view
or that it's invalid to try! They're still bugs nonetheless.

Please do let us know via Bugzilla if there's some quirks we need to add to ebuilds.

We also have a group of us interested in using Clang in #gentoo-arm on libera.chat (IRC) -- the channel is not super restricted to ARM chat.

Best,
sam

[-- Attachment #1.2: Type: text/html, Size: 3614 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Clang/LLVM profile

[Andreas K. Huettel]

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

> Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us
> are quite interested in this.
^ this

> - I'm not sure why you would need virtual/toolchain or virtual/binutils
> unless it's just for usage within bootstrapping scripts? Seems more like
> you could just remove gcc from @system and such?
^ this too

FWIW, a minimal chroot (corresponding to a stage3) rebuilds quite nicely with 
clang, with one exception (sys-libs/glibc obviously).

Being able to build glibc with clang is seen as a desirable long-term goal by 
glibc upstream, seems to be nontrivial to implement though.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

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