[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC cross compiler for ARM Cortex-A/R/M processors (was Bug#728388: ITP: gcc-arm-none-eabi)

On 11/01/2013 04:09 PM, Keith Packard wrote:
> Agustin Henze <tin@debian.org> writes:
>> * Only C language support. Do you disable c++ for some reason?
>> * Link time optimization disabled. Why?
> I wasn't going to test either of these, and I don't like shipping stuff
> that I can't test. If you're capable of enabling these and doing some
> testing, that'd be great.

Yes, I can work on it and do some test.

>> Disadvantages
>> * It's delivered without any prebuilt libc. You can't build a project "out of
>> the box".
> I'm currently using pdclib, which is kinda a disaster, but at least easy
> to build. I don't really want to encourage people to use that. Getting
> newlib built for this environment is definitely possible, but I haven't
> had a chance to work that out. It'd be separately packaged in any case,
> as I don't want to force the choice of libc on the users.

Yes, I agree it's better separate the libc in another package. I'll take a look
to pdclib, I've always used newlib and I never tried another.

> I doubt I'll have time to work on newlib before the end of the year at
> this rate though; it's definitely something I'd like to see happen.

Great! :). I can do this, gcc has integration with newlib and it isn't too
hard, I did it other times and with a little patience it works. I'm using
gcc+newlib for a while (with a cortex-M3) and it works very well. I'll try
newlib-nano too, seems pretty good idea.

>> * It's a lot of work maintain a toolchain working well. Therefore maintain in a
>> good shape the package applying some patches "by hand" can become in a
>> hard work.
> Yup. The patch sequence is very small at present, and I'm hoping that
> the CPU-specific patches are upstream by the next time I need to package
> this for debian. The goal is to have *zero* patches in all of these
> packages, and we're actually pretty close.

Ok, perfect.

>> I'll close the ITPs that I've created. If you are agree, we can follow the
>> discussion in debian-cross.
> Sounds good. As is my general practice, I don't like to work beyond my
> ability to test or deploy, so I've packaged only what I'm actively
> using. Having other people help out by adding the bits they want would
> be perfect from my perspective.

It's great, I want to see a good toolchain for bare metal in debian :) and I
can help with this. Are you using collab-maint? If not, could you upload it there?


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: