[gccsdk] GCCSDK GCC 4 status update

John Tytgat John.Tytgat at aaug.net
Thu May 31 15:02:43 PDT 2007

In message <0ef6cdeb4e.druck at druck.freeuk.net>
          "David J. Ruck" <druck at druck.org.uk> wrote:

> On 31 May 2007 John Tytgat <John.Tytgat at aaug.net> wrote:
> > It's been a while since my last update on the GCCSDK GCC 4 developments.
> > As mailed before the most up-to-date development status can be found at
> > <URL:http://www.riscos.info/index.php/GCCSDK_Development> but summerized
> > for the latest 4 months the highlights were:
> > - UnixLib became now a GCC-only ELF-only runtime library allowing us to
> >   focus on that usage alone.
> Not particularly happy about dropping Norcroft support, but you 
> started that some time ago, so I've had to fork off my own copy.
> The compatibility issues are some trivial header changes, but a
> more tricky bug in ObjAsm's conditional assembly support.

It is all matter of figuring out and deciding where we see our developer
time best spend.  Seen we didn't have any hands waiving volunteering to
further support Norcroft in UnixLib and it becoming more and more a hurdle
for the smooth ELF/GCC development, the conclusion was made.  I'm not saying
it is impossible but just that it distracts from the real goel we want
to reach.

I was one of the people who took care of Norcroft compatibility of UnixLib
for many years (cfr its ChangeLog) but came to a point that it nearly had
no advantages compared to GCC, on the contrary it wasn't cheap, particular
its yearly support scheme and when it comes to standards compliancy and C++
support, Norcroft turned out a bit bleak.  Also especially when switching
to cross-compiling development Norcroft speed advantage on RISC OS was no
longer relevant to me.  Well that was a personal conclusion and everybody
is free to do whatever he likes.

> > - We have module support for C programs fully working (including ELF
> >   based CMunge).  C++ support has some oddities which I don't fully
> >   understand what's going on and what a solution could be.  If someone
> >   feels challenged by this, by all means, talk to me and have go.
> Well CFront had some nasty bug involving static initialisers (I forget 
> the exact details). I got away with writing one C++ module and thought 
> better of it after that. I don't expect people rushed out to build G++ 
> modules when it became possible, so its not urgent, but would be nice 
> to have eventually.

Actually since GCCSDK 3.4.5 Release 1 (15 Feb 2006) you can build C++ modules
surpasing Norcroft here.  Not sure to what extend it got used but recently
C++ rar (?) based module for SparkFS was discussed in dpilling's mailing
list I believe.

> > From the remaining items of
> > <URL:http://www.riscos.info/index.php/GCCSDK_Development#On_the_agenda>
> > is the native RISC OS build the most important one.
> Another alternative for debugging support is for me to work out the 
> DWARF2 format for ARMalyser and then pass on the details to Swiss Nik 
> so he can put it in DeskDebug. Unfortumately he's an assembler 
> programmer with no knowledge of C, so he'll do something with it, but 
> it might not be ideal for C programmers.

Certainly if he could support ELF based C programs that would be fantastic

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list