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@xxxxxxxxxx _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
