On Tue, Nov 29, 2011 at 2:17 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 11/23/2011 06:59 PM, Michael Hope wrote:
> Hi Jon. I've cc'ed Marcin and Ricardo who are working on the Linaro
> platform side.
Hi Michael, Marcin and Ricardo. I'm working with Jon on or ARM endeavors
and thought I'd follow-up since compilers are one of the few areas where I
have more expertise than he. Comments inline below.
> Currently we have a Linaro + Ubuntu sauce cross compiler, plain Linaro
> cross compiler, and plain Linaro native compiler. We're working on a
> plain tarball cross compiler that runs on generic Linux or Windows as
Fedora sauce is essentially the rpm packaging. It's actually quite
straight-forward to turn a basic build script (configure; make all install)
into an rpm, so the technical effort needed in this endeavor may be minor.
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
> The Linaro + Ubuntu sauce cross compiler is in the Ubuntu archive
> at least Natty onwards and Marcin is working on making these available
> in Debian. The plain Linaro compilers are in a PPA, don't include the
> Ubuntu specific patches, and are more up to date.
> You probably want your default cross compiler to be the same as the
> native compiler to reduce surprises so you'll probably want both a FSF
> and Linaro cross compiler.
One of the more complicated elements of Fedora Linaro integration that
Fedora maintains its own gcc. This is essentially FSF stable plus rpm
sauce. There is definitely room for a Linaro cross compiler. There might
be room for a Linaro native compiler.
There are a few avenues we would like to explore:
1. Making the Linaro cross package set available for i686, x86_64, armv7hl
and possibly armv5tel rpm-based distributions such as Fedora and RHEL.
These same packages would likely work on SuSE, Mandriva, etc. The end goal
is to get a wider audience able to use the same tool set, regardless of
their Linux distribution. This wouldn't need to be limited to gcc and
binutils- any package that makes sense to run on a non-arm system might be a
valid candidate including qemu, cross-gdb, etc as you mentioned below. My
general assumption is that this would be a pure-Linaro set of packages so
that the libc linaro-gcc links with would be linaro-libc, rather than
Fedora-arm libc- that sort of thing.
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.
2. Making the Linaro native package set available on Fedora ARM.
tricky and will be both technically interesting and perhaps controversial.
Questions to be answered include things like: Should linaro gcc replace the
system gcc? Whose libc should be used?
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
> Regarding next steps, I'm afraid we don't have much
> knowledge in Linaro but are happy to help when you run into problems
> and do any bug triage. Any thoughts on where the scripts or binaries
> would be hosted, or who would keep it up to date?
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.
> You might want Linaro GDB, QEMU, and the work that's going on
> libjpeg-turbo as well. We do the changes in Ubuntu to demonstrate the
> improvements, but I wonder if there's a way of sharing the whats and
> whys so other distros can consider making the same changes.
Fedora generally pulls from the official upstream so anything that gets
pushed there trickles back down eventually. It's not exactly ideal for
cooperating on multi-package architecture-specific distribution such as
Linaro produces, but the changes do make their way eventually. In Fedora
ARM we've reinvented the wheel a few times, as it were, and would like to
bridge the upstream gap wherever feasible.
Would you all be interested in a conference call to discuss?
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