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.

We have a mix of pre-built cross and native compilers that ship with Ubuntu or come in a PPA and it would be great to have something similar for Fedora.

Indeed, we'd love to see the Linaro package set become available to Fedora as well.

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 well.

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.

The Linaro + Ubuntu sauce cross compiler is in the Ubuntu archive from 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.

2. Making the Linaro native package set available on Fedora ARM. This is 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?

Regarding next steps, I'm afraid we don't have much Fedora packaging 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.

You might want Linaro GDB, QEMU, and the work that's going on into 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?

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.