[gccsdk] Development roadmap proposal
John.Tytgat at aaug.net
Sun May 23 17:18:50 PDT 2010
In message <ae6c5cd050.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> 4. Merge SCL stubs (libscl) and UnixLib : not really convinced yet this
> would be an overall win but again worthwhile to investigate.
> - The reasoning is that currently libscl is missing out network/socket
> support which is a pity as we can't build network related modules
> (I don't think libscl has any advantages on UnixLib for normal
> applications, binary footprint size aside).
> - We could solve this particular network issue by migrating the
> relevant bits from UnixLib to libscl but it could very well be that
> we get nearly freebies as well by doing the libscl & UnixLib
> merge : pthread support (perhaps), C++ (because missing runtime
> routines are available as UnixLib runtime routines).
> - It would eliminate several nasty hacks in our gcc tree to have
> two runtime libraries which are enabled/disabled depending on the
> multilib configuration we're building.
> The basic idea is that we still have this one unified runtime library
> between SCL and UnixLib mode based on the presence/absence of
> -mlibscl option in the current multilib configuration.
> This would also help out with point 5.
> - It risks to complicate the code base.
I've tried out this idea in a separate branch and it turns out more or
less what I thought it would be:
- SCL based programs have now network support (back).
- SCL based programs can now be written in C++ and use STL. We still
need to investigate exceptions and module code.
- Less ugly hacks in our gcc patches to have multiple runtime libraries
in one build tree as now from gcc pov there is only one runtime
The price to pay is indeed that UnixLib becomes slightly more complicated.
After weighting the pros & cons I've decided that it was still worthwhile
to go for it so I've merged this change to trunk. There are still some
rough edges to smoothen out.
So for those following the trunk changes and building their own
cross-compiler, please do now a full clean build.
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc