Hello I think Sergei is not alone.
Standardized tool-chain is important contribution to eCos' stability. It will also facilitate bug hunting by making test cases reproducible. I would mention that information on library versions (vxWidgets, Tcl/Tk) used for eCos 3.0 configuration tools is also important. At the end if it is not decided yet, I would suggest to get some fresh GCC release (4.2... or newer). Best regards Ilija Sergei Gavrikov wrote: > Hello > > I wonder what GNU toolchain will become a companion eCos 3.0? > > Official toolchains for eCos 2.0 were based on GCC 3.2.1, binutils > 2.13.1 and newlib-1.11.0. Anyone can build it from sources or download > them from eCos centric ftp site. Many of developers use GCC 3.4.X (last > in line is 3.4.6) or GCC 4.X.X flavors and as a result the differents > binutils, newlib, gdb versions. In the most their toolchains are a home > cooked (geek) things. > > Why did I ask about? If we will know the announced GNU toolchain version > for eCos 3.0, we would build same the toolchains, test them, discuss the > results, share the build scripts or/and patches, etc. and at the least > clean up the build flags for our target in CDL files. > > For example, GCC-3.2.1 has compile/build options which had gone away in > years, and the attempts to build some targets against new toolchains > will fail. Perhaps, it is a forced problem and eCosCentric is cooking, > testing the new toolchains for eCos 3.0 tag just now :-). I don't know. > > Another "solution" would be an introduction some generic CDL option(s): > either toolchain or ecos "generation" or something like it, using same > option(s), we would more flex tune up the platform build flags in the > platform CDL files for today and future needs. > > What does community know about? > > Thanks, > > Sergei > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
