Re: Large patch to merge in changes for gcc 4.3

["simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>]

Jonathan Larmour wrote:
> The attached patch is a merge of changes from eCosCentric's internal tree
> to anoncvs, in order to support updated tools based on GCC 4.3.2. We have
> these updated tools stable, and this patch is the precursor to announcing
> the availability of the tools for wider testing.
>   

Do you know if this patch also fixes debugging synth binaries with gdb 
6.8 on Debian/Ubuntu, which were compiled with a new 4.x toolchain? I 
currently moved back to a legacy gcc (3.2.1) for synth debugging, which 
of course is very sub-optimal. I will get my own repo up to date once 
you also merged flash v2, so I can test again.

> Many of the changes here are required. Many are included for incidental
> reasons such as warning cleanups. Quite a few more are included for no
> better reason than that picking them apart would increase future merge
> headache. That's also why you may see some bits that aren't (yet) relevant
> for anoncvs. But leave them in as they'll become relevant eventually :-).
>
> I've tried to marry the changes with ChangeLog entries - apologies for any
> discrepancies - something like SVN would make taking individual changesets
> much easier!
>   

Is there internal discussion about moving to another VCS? I think most 
of the community would agree.

> Therefore if we're going to be touching all HAL's CYGBLD_GLOBAL_CFLAGS,
> it's an opportunity to centralise these warning flags, which are entirely
> generic and are distributed identically across all HALs. I propose adding a
> CYGBLD_GLOBAL_WARNFLAGS CDL option in hal/common. And I will remove all the
> standard warning flags[1] from all HALs, and replace it with a reference to
> that option. More specifically I suggest that CYGBLD_GLOBAL_WARNFLAGS is an
> option which consists of a concatenation of CYGBLD_GLOBAL_WARNFLAGS_C,
> CYGBLD_GLOBAL_WARNFLAGS_CXX and CYGBLD_GLOBAL_WARNFLAGS_COMMON. Each of
> these takes their default_value from an identically named option with a
> _DEFAULT suffix. This allows package CDL to control the default, as well as
> letting users override it. It also starts to give us a route to avoid the
> horrible hackery in pkgconf/rules.mak to eliminate language-specific flags
> by replacing it with something properly controlled. If anyone has a better
> proposal, I'd like to hear it, although be warned that if it is more
> effort, then they can consider themselves automatically volunteered to do it!
>   

To me this sounds good, and it will certainly make our lives easier.

Thanks for your efforts to the 3.0 release!

Simon