Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-26 Thread Brendan Conoboy
On 05/25/2012 08:27 PM, Ralf Corsepius wrote: Why have more than one gcc or binutils for arm-eabi at all? Just add multilibs for the extra variants of interest. You can even split the multilibs out into subpackages if it matters. This is simply not true. A gcc targeting glibc/linux is entirely

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-25 Thread Ralf Corsepius
On 05/25/2012 10:45 PM, Brendan Conoboy wrote: On 05/25/2012 12:10 PM, Przemek Klosowski wrote: I recomment to implement 2 separate toolchains with separate packages. Well, maybe that's true in the interest of expediency, but it's hardly an optimal solution. Would it at least be possible to li

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-25 Thread William Cohen
On 05/23/2012 12:14 PM, Ralf Corsepius wrote: > On 05/23/2012 06:07 PM, Rob Spanton wrote: >> Hi, >> >> There are an increasing number of ARM Cortex-M based boards around, and >> I'd like to get a cross-compilation toolchain for them into the Fedora >> repositories. I'd like to make it just as eas

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-25 Thread Brendan Conoboy
On 05/25/2012 12:10 PM, Przemek Klosowski wrote: I recomment to implement 2 separate toolchains with separate packages. Well, maybe that's true in the interest of expediency, but it's hardly an optimal solution. Would it at least be possible to list reasons why binutils have to be different, wi

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-25 Thread Przemek Klosowski
On 05/23/2012 12:14 PM, Ralf Corsepius wrote: On 05/23/2012 06:07 PM, Rob Spanton wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? No, this will hardly work and would be a nigh

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-24 Thread Ralf Corsepius
On 05/25/2012 05:29 AM, Ralf Corsepius wrote: On 05/24/2012 03:21 PM, Rob Spanton wrote: Hi Ralf, I wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? Ralf wrote: No, this wi

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-24 Thread Ralf Corsepius
On 05/24/2012 03:21 PM, Rob Spanton wrote: Hi Ralf, I wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? Ralf wrote: No, this will hardly work and would be a nightmare to main

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-24 Thread Rob Spanton
Hi Ralf, I wrote: > So is it best to attempt to get one arm-binutils package and remove > redundancy, or is it going to be more productive to just put up with > the redundancy for now? Ralf wrote: > No, this will hardly work and would be a nightmare to maintain. I had guessed that binutils didn'

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-23 Thread Eric Smith
Rob Spanton wrote: There are an increasing number of ARM Cortex-M based boards around, and I'd like to get a cross-compilation toolchain for them into the Fedora repositories. I hope you're more successful with that than I was. I found a resounding lack of interest when I put an arm-none-eabi

Re: Strategy for packaging an ARM Cortex-M toolchain

2012-05-23 Thread Ralf Corsepius
On 05/23/2012 06:07 PM, Rob Spanton wrote: Hi, There are an increasing number of ARM Cortex-M based boards around, and I'd like to get a cross-compilation toolchain for them into the Fedora repositories. I'd like to make it just as easy to compile for Cortex-M chips under Fedora as it is to com

Strategy for packaging an ARM Cortex-M toolchain

2012-05-23 Thread Rob Spanton
Hi, There are an increasing number of ARM Cortex-M based boards around, and I'd like to get a cross-compilation toolchain for them into the Fedora repositories. I'd like to make it just as easy to compile for Cortex-M chips under Fedora as it is to compile for AVR or MSP430 targets right now (i.e