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(a)redhat.com