Comment by Rochus
1 day ago
> it does not matter whether it is huge and complex
I was talking about the migration effort and usage complexity, not what the compiler or linker actually sees. It may well be that Newlib can be configured for every conceivable application, but it was more important to me not to have a such a behemoth and bag full of surprises in the project with preprocessor rules and dependencies that a single developer can hardly understand or keep track of. My solution is lean, complete, and works with standard-conforming compilers on each platform I need it.
The standard C library does not belong into any project, but it normally is shared together with cross-compilers, linkers and other tools by all projects that target a certain kind of hardware architecture.
So whatever preprocessor rules and dependencies may be needed to build the tool chain, they do not have any influence on the building processes for the software projects used to develop applications.
The building of the tool chain is done again only when new tool versions become available, not during the development of applications.
I assume that you have encountered problems because you have desired to build newlib with something else than gcc + binutils, with which it can be built immediately, as delivered.
Even if for some weird reason the use of gcc is avoided for the intended application, that should have not required the use of a newlib compiled with something else than gcc, as it should be linked without problems with any other ELF object files.
> The standard C library does not belong into any project
Why not? Have a look at https://github.com/rochus-keller/Eigen.
> because you have desired to build newlib with something else than gcc + binutils
Well, the whole point was to make it compatible with my own C compilers.
That project is interesting, but it just proves my point, because that is not a software project for some concrete application intended to be run on some embedded computer, but it is a tool chain, i.e. an alternative for commonly used tool chains such as gcc + binutils + newlib.
For its intended purpose, i.e. as what must be added to gcc and binutils for obtaining a complete tool chain usable for the cross-compilation and linking of executable applications for any embedded computer, newlib works fine, with minimal headaches.
If instead of using it as intended, you want to integrate it as a component in a new and different tool chain, then I completely agree with what you have found out, that it is not a good choice.
I have reacted to your first comment because that seemed to imply that newlib is not fit for its purpose of being used in embedded programming applications, which is definitely false.
You have tried to use if for something very different, and in that context you are right, but you should have explained more of that in order to avoid confusions.
Your project seems interesting, but like in most such projects you should add on the initial page some rationale for the existence of the project, i.e. which are the features where it attempts to be different from the better known alternatives based on gcc or clang.
Following the links, one eventually reaches this succinct explanation:
"The Eigen Compiler Suite is a completely self-contained collection of software development tools. It exists to be recognized and adopted as a free development toolchain which is hopefully as useful and easy to use as its source code is intended to be approachable and comprehensible for developers and students wanting to learn, maintain, and customize a complete toolchain."
This does not mention any attempts of being better than alternatives in any direction, except for being much easier to modify if someone desires to implement some kind of compiler/linker customization.
This recommends it mostly for experimental projects, not for production projects. The former are important too, but it is good to know for what it is suitable.
1 reply →