[fedora-arm] Linaro toolchains and Fedora

[Brendan Conoboy]

On 11/30/2011 03:16 PM, Ricardo Salveti wrote:
> I believe it could simply target the Fedora ARM port, but then don't
> know if it'll be easily compatible with other rpm-based distros.

Following up on the previous description of source rpms to binary rpms, 
sys-roots are tricky to handle in this way.  In theory you could produce 
one set of gcc rpms that work with just about any rpm-based distro, then 
a number of sys-root rpms that can be used interchangeably to target 
Fedora, or SuSe, etc.  You'd still need one for the gcc build to make 
target libraries build, but there should be sufficient compatibility 
there that it would be hard to go wrong.

> Well, guess making the Linaro native package available should help you
> understanding if there's any need to do the switch. Even if not
> entirely switching to the Linaro GCC, you could simply make the
> package available for the people to try and help tracking and
> comparing bugs and issues with the native distro GCC.

Yes, this is exactly one of the great abilities having a side-by-side 
native compiler brings: Sanity check for our own compiler (And 
contrary-wise as well).

> This is solved at our LEBs by enabling the packaging recipes at
> Launchpad, that then merges the packaging souce with the Linaro GCC
> trunk and push the package to be automatically built at our PPAs. If
> you have some sort of a similar system, that could trigger new
> packages and rebuilds once the Linaro GCC bzr tree gets updated, I
> believe we can at least help setting up the environment and building
> the first packages.

Can you provide some more detail on how your build system works?  How do 
package builders know there is work to do?  Can outside-of-Linaro 
builders get involved?

> To have proper maintenance and such would then be a quite overhead,
> and would need an agreement with the management.

Let us know if there are others in Linaro with whom we should be 
broaching this topic.  At this point we're really feeling out the 
theoretical possibilities, but hope to take it somewhere concrete in the 
near future.  Thanks!

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