[fedora-arm] Linaro toolchains and Fedora

Brendan Conoboy blc at redhat.com
Thu Dec 1 06:44:25 UTC 2011


On 11/29/2011 05:17 PM, Michael Hope wrote:
> Sounds good.  Note that Linaro produce a drop in replacement for FSF
> GCC so we should be able to re-use your existing packaging.
>
> How about splitting things up, such as gcc vs g++ vs Fortran vs
> binutils packages?

We have a concept of source rpms and binary rpms.  A source rpm is 
(typically) composed of a source tarball, 0 or more patches to be 
applied to it, and a recipe that turns building the sources and patches 
into one or more binary rpms.  In the case of gcc we split out binary 
rpms by language.  On my desktop at home for instance I have these 
installed:

gcc-java-4.6.2-1.fc16.x86_64
gcc-gfortran-4.6.2-1.fc16.x86_64
gcc-c++-4.6.2-1.fc16.x86_64
gcc-4.6.2-1.fc16.x86_64
gcc-gnat-4.6.2-1.fc16.x86_64

But they all came from the same source rpm.  Binutils, being a different 
project, gets its own source and binary rpm.

> We don't have a libc as there hasn't been the need.  The cross
> compiler could either target the Fedora ARM port or the Linaro LEBs.

This is interesting.  Typically if you have an arm-linux-* compiler, 
it's been built with sysroot support.  I'd just assumed you are 
providing a standard sysroot that accompanied gcc.  Last I looked this 
was necessary for building target libraries (libgcc_s, libstdc++, etc). 
  Is the Ubuntu libc being brought in for this purpose?  If that were 
the case then sure, we'd want the Fedora libc to be used.  On the other 
hand, let's say we're talking about ARMv8 where there is not yet a 
Fedora or Ubuntu build, as such, what's the plan there?  I guess I 
better look at your total package list to understand what is and isn't 
included.

> Marcin is working on a gcc-linaro package that you can install
> alongside the native compiler.  The other question of 'could Fedora
> switch to Linaro GCC' is a big one but we do support ARMv7, ARMv5,
> x86_64, and i386, will investigate bugs found on other platforms, and
> have been used by Ubuntu for some time.  Those should help calm some
> nerves :)

Yeah, an along-side package will be a good start. I can't see Fedora 
itself diverging from FSF-upstream, but enabling end-users to pick the 
right compiler for the job is very desirable (This is actually part of 
my group's day job with GNUPro).

>> That's the big question- who would support this endeavor?  We have precedent
>> for #1 in Fedora with the mingw cross compiler, but that is very
>> Fedora-centric.  To bring in the wider rpm-based community, Linaro is the
>> logical place to host as it is the "source."  With that in mind, what would
>> we need to do to make rpms automagicaly build any time debs are produced?
>>   Once packages are in rpm format it's very straight-forward for anybody to
>> start using them, pulling updates, etc.
>
> I'd have to bring that up with management.  We'll support you if you
> use it but producing and maintaining the packaging is an overhead.

This could be handled in a number of ways, depending on how builds are 
triggered and what external interfaces are available.  Let's say, 
hypothetically, that we created a build system that poked Linaro's 
servers once an hour looking for package updates and automatically 
downloaded source updates, did builds, and pushed the results somewhere 
accessible.  While the setup for such a system is heavy, ongoing 
maintenance would generally be lighter.  Now, what if instead of an 
automated spider, there was instead a mechanism wherein if a build was 
initiated by Linaro, it triggered that same mechanism?  We're very 
interested in collaboration and looking to understand the boundaries in 
which we can work together.  Since your experience to-date doesn't have 
any Fedora-ness in it, I'm assuming RH would need to lay foundation for 
this sort of multi-distro build idea.

> That would be good.  I'm travelling next week so the week of the 12th
> is best.  Let's see where we go over email and organise a call past
> that.

Okay, let's stick with e-mail for now.

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com


More information about the arm mailing list