Petr Stehlik wrote:
Sounds like MiNTLib should become a patch to glibc - then tracking the changes by GNU would be easier, perhaps :)
Yes, that is the definitive solution.But the glibc is huge, I heard it can be difficult to port it to something other than Linux. The situation may be better now.
However, there are alternatives to glibc, for example Newlib, uclibc, dietlibc...
Newlib is a very good choice: it has been designed to be portable. It is required to implement less than 10 "system calls" in order to get it work on a new system. I even managed to let it work on plain TOS as a replacement for the MiNTLib ;-) (be quiet: it was only a very incomplete test).
However, Newlib has less functionality than glibc (for example, that damn obstream stuff is not present). For information, Cygwin uses Newlib, not glibc. The good news is that most makefiles of GNU software are aware of Newlib, it can ease porting them.
Unfortunately, I guess the MiNTLib has been heavily patched from the original sources, so it could be extremely difficult to port the added functionalities to another libc. But I think it is the only way to get the new functionalities and bugfixes from the community. I don't think the MiNTLib could survive without this.
-- Vincent Rivière