--Apple-Mail=_4D86EE16-2BD3-4F4D-957E-957644385742
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
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
--Apple-Mail=_4D86EE16-2BD3-4F4D-957E-957644385742
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><
div class="">On 29 Nov 2021, at 01:45, 2b57 <<a href="mailto:
2b57@protonmail.com" class="">
2b57@protonmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Sorry all, it seems that I've confused the lists. I'll
forward this to user<br class=""></div><div class=""><br class=""></div><div class="protonmail_quote">
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br class="">
On Monday, November 29th, 2021 at 2:42 AM, 2b57 <<a href="mailto:
2b57@protonmail.com" class="">
2b57@protonmail.com</a>> wrote:<br class="">
<blockquote class="protonmail_quote" type="cite">
<div class="">Hello all,<br class=""></div><div class=""><br class=""></div><div class="">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!<br class=""></div><div class=""><br class=""></div><div class="">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...<br class=""></div><div class=""><br class=""></div><div class="">Anyway, I'd appreciate any feedback and suggestions, since I'm sure I'm not the only one interested in this
topic. <br class=""></div><div class=""><br class=""></div><div class="">Grab the src here: <a href="
https://github.com/2b57/toolchain-clang" rel="noreferrer nofollow noopener" target="_blank" class="">
https://github.com/2b57/toolchain-clang</a><br class=
""></div>
</blockquote><br class="">
</div></div></blockquote><br class=""></div><div>Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us are quite interested in this.</div><div><br class=""></div><div>That said, a few notes:</div><div>- 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?</div><div><br class=""></div><div>- _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</div><div>or that it's invalid to try! They're still bugs nonetheless.</div><div><br class=""></
Please do let us know via Bugzilla if there's some quirks we need to add to ebuilds.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">sam</div></body></html>
--Apple-Mail=_4D86EE16-2BD3-4F4D-957E-957644385742--
-----BEGIN PGP SIGNATURE-----
iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmGkMj9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDsiEAf+PNrs22KWx48ID47oyJMZoqHniPnUBs8Ac3AIqVezB597r7YJEDWW0GWd TCvZol/TBQQj9uGRZZmKiSZ/9wHzB8lxDlxMc/SPolBlX85aDoVcaQZwJxDY8d8f yJhoWohBtHw2ih0u7pXDTLSojEhp6UBB8IhTNI6ANvbDJIDywmdgPM+9+Uy+Aa9r +6APtvKzjNlfoLf/kh28QUvgMdWaTnt+N7TFQ5QiR2BhhaiAGeTKacWC+PxWKf+M H+LrSJqdogOMjS1qUNxl5ypR9qKXDezluUyFneO/0CdaZuDSsGJUGVuJJbNkhUcP PF571MOHW3T1lVTEla8FZOrDE0rvaA==
=wqEi
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)