Alternative to newlib

[KemyLand]

Don't misunderstand me. I've managed to build newlib, but its somewhat... difficult to work on. It appears as I should have heard Sortie (his wiki page says "Don't use newlib" ). Also, the wiki appears to be *really* outdated in this topic. I don't want to create a libc which will never be even able to link to cross-compiled standard Unix utilities. What can you say about the topic? What's a good alternative to newlib? Without a libc, I'm not even able to port cat

[alexfru]

Have a look at the standard library I'm implementing for Smaller C.
It's sufficient for most things standard C (~100 library functions on top of ~20 system calls). My compiler recompiles with it for DOS and Windows already.

[sortie]

I'll respond by rewriting the wiki article on the matter: http://wiki.osdev.org/C_Library

First of all, you should decide whether you want a good operating system, or just a operating system. If you want a good one, that means you should likely write your own libc, or port one of the real high-quality libcs (and perhaps not do that if they aren't good enough). Or, if you don't want to surpass existing operating systems, you can use whatever libc gets the job done.

That's why I said “Don't use newlib” in my user page. I assume you wish to make a good operating system. I don't want to generally recommend not doing things well. See the warranty section on my user page. :P

I didn't spell it out clearly in the article, but the situation isn't very good. newlib is supposedly a piece of **** compared to a real, excellent libc. GNU libc is big and not terribly impressive in terms of quality, but would give you less problems when porting GNU software that inexplicitly only works well with glibc. pdclib is decent, but only does the standard C parts, you'll have to supply the POSIX parts yourself. If you want a real libc of decent quality, may I recommend musl? It's not the easy path and there it requires a lot of your kernel, you basically have to implement the Linux system call ABI. That's actually not too bad, and you can enhance musl if you wish.

I have personally written my own libc. It was a considerable effort, and while it's hardly perfect yet, it really does get the job done and I'm continuously improving it and its standards compliance. A lot of third party software works with it currently. I'd recommend using it, but it has no kernel portability layer: It is well integrated with my operating system by design. That's a bit of a sad fact, if a libc is good and tailored for one system, it's not reusable; and if it is reusable, it has a portability layer that makes things more complicated and can't take advantage of a single system.

[KemyLand]

I'm okay with writing my own C Library, if only ISO C11 was supported, but the POSIX.1/.2 layers simply makes me give up with some *much* overbloat of (type)defines which are useless a great part of the time. I see your points, and will try to make a ISO C11 libc for Bluesky myself

BTW, isn't there a summarized version of the POSIX header standards I could use? Here's where my mind says "Automate this stuff with Python (the headers' writing) and go to kernel code!"

[sortie]

You don't have to be complete; you only need to have a subset of C and POSIX, but that subset must be compliant and correct (or bad things happen).

You really don't have to supply full headers, it won't even be useful. Just start with no headers and compile the software you wish to port. You will get errors that a header is missing. Implement that header. Repeat. When errors comes because a header didn't supply something, supply that. If you added a function, implement it. Repeat. Run the software on your OS, if it fails, debug it and fix your libc. Repeat. Congratulations, you ported something.

The POSIX-2008 standard has a list of headers. That is useful.

[KemyLand]

You don't have to be complete; you only need to have a subset of C and POSIX, but that subset must be compliant and correct (or bad things happen).

One of the problems with the compile, supply, compile... way is that GCC *needs* the headers to compile itself. So how can I at least build GCC, without headers? If I use another library's headers, I'll possibly provide some stuff on headers, that's not on the libc.a. I've always preffered GCC's bloated up errors over LD's simple but confusing errors

Sidenote: I'm writting vsnprintf() right now with all the standard (sub-)specifiers

[sortie]

See Hosted_GCC_Cross-Compiler.