LLVM/Clang seems to be the future as far as open source compilers go. The FreeBSD developers switched to LLVM/Clang in FreeBSD 9 and the Debian project appears to be considering a switch as well. They did a survey that shows that only 8.8% of their packages fail to build with LLVM/Clang 3.0:
It is probably a good time to look into building Gentoo with LLVM/Clang. FreeBSD upstream has already switched, so this should work well for Gentoo/FreeBSD. With some work, this could be leveraged by Gentoo Linux and Gentoo Prefix as well.
As per a chat I had with bonsaikitten (Patrick Lauer) in IRC, I am filing this bug to serve as a tracker for progress on this.
I found this project and then I think it's may be interesting:
They are porting the OpenBSD useland for Linux.
In Arch Linux AUR are some PKGBUILDs about, but I don't know if already functional.
I'd love to start a project within the Gentoo community to start the transition from the inferior GCC to Clang. Would be a very interesting and rewarding project I think.
(In reply to comment #2)
> I'd love to start a project within the Gentoo community to start the
> transition from the inferior GCC to Clang. Would be a very interesting and
> rewarding project I think.
I am going to blame Hurricane Sandy for putting me behind on bug mail. Gentoo is quite large and I am one developer. It would be better to do this as a community effort and if people are interested in that, then it would be best to take this to the gentoo-dev mailing list. If you are strongly interested in doing this, I suggest that you subscribe to the gentoo-dev mailing list and send an email to the list about this. Instructions on how to subscribe are on the following webpage:
If we want have systemwide-clang
first we need remove dependencies from gcc
remove from all packages
and first remove from llvm ebuild
llvm don't need dependency on gcc
we can check gcc version at pkg_pretend
and throw error if have broken gcc version
but this check need only if we use gcc as CC for build llvm.
Determine which compiler we use we can in pkg_pretend,
but we need remove gcc_version and Co from toolchain-funcs.eclass and split that in separate gcc-version.eclass
use CPP for determine version of gcc,
but for clang it's work too
clang return 4.2 if CPP=clang and call gcc-version
what does what mean?
and determine compiler from tc-getCC
it's not best way
what if CC=cc and cc it's symlink to clang or script that call clang?
maybe we have better solution?
PS: dependencies to gcc don't need for all package
systemwide compiler it's part of system
and we have systemwide compiler in /usr/portage/profile/../packages
systemwide compiler always have last supported version
and if some package need specific version of system wide compiler
we should determine this in pkg_pretend
There are a couple missing dependencies:
bug 417795 (dev-libs/openssl)
bug 458932 (media-libs/libaacplus)
as well as a few I just filed:
bug 502450 (app-crypt/seahorse)
bug 502452 (dev-lang/tcc)
bug 502454 (media-libs/gstreamer)
bug 502458 (net-libs/glib-networking)
bug 502460 (net-libs/libsoup)
bug 502462 (sci-libs/fftw)
bug 502464 (sys-apps/memtest86+)
bug 502466 (sys-apps/ipmiutil)
bug 502470 (sys-boot/efibootmgr)
bug 502472 (sys-devel/autogen)
bug 502474 (sys-fs/udisks)
bug 502476 (sys-libs/glibc)
bug 502478 (x11-libs/cairo)
bug 502480 (x11-misc/lightdm)
btw, bugzilla seems to have an off by one, it's skipping all odd numbers. See above numbers ;)
Redacting comment 6 per request:
> I'm slowly (manually) moving lots of my packages over to LLVM/Clang (using
> the environment portage feature).
> Here's a gist of packages that work! (I'll update it periodically).
> Once I'm finished with my porting, I'll also file a bug report for every
> package that _doesn't_ work.
> [redacted dead URL]