2016-08-22 17:59 GMT+01:00 Alex Bradbury <asb(a)asbradbury.org>:
On 22 August 2016 at 15:20, Manuel A. Fernandez Montecelo
> As for what's next... Having the changes upstreamed in the GNU toolchain
> would be very nice, to be able to put all that work in the Debian
> infrastructure. I am not sure that it could be made to work with LLVM,
> but even in that case GNU libc is needed even for the non-Linux Debian
> ports (FreeBSD and Hurd), so at least that and probably GNU binutils
> would be necessary. I'm not sure if the upstreaming of those components
> would happen during this year, but let's hope for the best :-)
Yes, Sylvestre Ledru has I think done a lot of work using Clang to
build Debian but it's still easier to just use gcc as that's what the
packages are built with on other architectures. Plus as you suggest,
we'd still want GNU binutils as LLD isn't really mature yet.
The last rebuild from Sylvestre was back in March 2015, according to
, last blog entry in 2014. I knew that I hadn't heard about him in
a while, just didn't remember exactly how long.
The results are quite good, ~6% instead of 10~12% or so in the
previous runs that I remembered . The key is if the packages that
fail are unimportant (e.g. games) and fixable, or if upstream refuses
or is highly uninterested to fix them, as it is the case e.g. with the
Linux kernel (AFAIK).
Even if the software itself can be compiled with LLVM, perhaps the
problem lies in some characteristics of the Debian packaging, and
getting changes to 1300 packages (or even 10% of that) is a lot of
 I am not sure how the statistics were gathered, though. 22k is
about the total number of packages in the whole archive, and vasts
amounts of packages do not depend on a C/C++/Fortran/etc compiler at
all -- hundreds of packages for Ruby, Haskell, Java, Python, Perl...
and about 50% of the whole set are not binaries (data and similar).
So 1320 packages is a quite higher percentage if we only take into
account the ones that need "GCC", probably 6k or 8k.
> My other goal is to make the building process self-hosting and
> mostly) automatic, and keep things up-to-date with the updated packages
> as they enter the archive. I'm almost there, but the unreliability 
> and shortcomings  of Spike and Qemu (and lack of alternatives) are
> blocking this at the moment.
More automation definitely sounds like the way to go. It seems as
though the QEMU work is getting increased attention, probably even
more so after Sagar's talk at the QEMU/KVM forum (this week?)
Yep, fingers crossed!
Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com>