Reimplementing glibc.

[whowhatwhere]

Yes, it's a crazy idea; I admit that.
If you could make any changes you wanted and reconstruct it (following or not following standards, in case you were wondering) how would you do it?

[Combuster]

since reimplementing glibc is basically equivalent to writing a libc from scratch, does it work if I point to PDClib? (If I get my ISP to work well enough to not have me leech off my neighbours' wireless, link to the source with my additions is in my OS, see signature)

[whowhatwhere]

since reimplementing glibc is basically equivalent to writing a libc from scratch, does it work if I point to PDClib? (If I get my ISP to work well enough to not have me leech off my neighbours' wireless, link to the source with my additions is in my OS, see signature)

It does.
What changes have been made that make it different from glibc, other than the license?

[Combuster]

Only about a third of that version of PDClib is actually my own writing, but the primary idea was that it is standards compliant (no gcc extentions!) and has as little OS dependencies and assumptions as possible, basically maximizing portability.

The license is primarily a matter of taste, but if you can be coerced, feel free to read the rant that comes with it

[01000101]

I'd suggest steering away from PDCLib in favor of a more well-tested proven library such as uClibc (extremely easy build/port) or newlib (documented in our wiki).

[Solar]

I'd suggest steering away from PDCLib in favor of a more well-tested proven library...

Huh, thanks.

It's easy to make blanket statements like that. Hey, I suggest steering away from any of the hobby OS'es here, in favor of more well-tested, proven operating systems.

I accept criticism on PDCLib on many levels. Nobody is perfect, the lib is far from finished, the licensing situation isn't perfect, yadda yadda. But what you are doing here is a bit rich, really.

Do you have anything to back up your - elegantly unspoken - claim that (what is available of) PDCLib is buggy, or less than well-tested, or are you just spreading FUD over a fellow OSDev netizen's project out of general principles?

[Combuster]

Its proven enough to be able to run the freebasic runtime on top of it. That and we were discussing libc reimplementations

[whowhatwhere]

I'd suggest steering away from PDCLib in favor of a more well-tested proven library such as uClibc (extremely easy build/port) or newlib (documented in our wiki).

That's one of the most frightening statements I've heard in a long time.
Have you ever tried to use uclibc for real applications, other than embedded stuff? Among quite a number of things, it's miserable at threading?

[01000101]

I think I made a mistake. I apologize to Solar, I admit confusing PDClib with PDPClib. I've never used PDClib, I was talking about my experience with PDPClib. Sorry guys

[whowhatwhere]

Personally, I've started on my own C library, but I have issues about if following POSIX to the letter is such a great idea. Some parts seem obvious when you look at them, but when it comes down to actually writing the code, it gets very vague and doesn't accurately address some issues around certain environments.

My idea was that glibc was too bloated from a code size point of view. Having a 1.4MB shared library being a single point of failure for an entire system disturbs me. As well, I find there are GNU-specific additions (like GCC extensions, as mentioned) that don't work. There's just too much crap in one place to fail. I find there are unsightly problems with the way dynamic linking and library namespaces are in a common linux distribution. Having a massive library containing everything from threading, to a memory manager, to elf/ld hooks, to nss/pam, to selinux, etc. etc. is a problem.

Along with an FHS redesign paper that a friend worked on, my solution is a new libc that contains only the absolute necessary requirements to get from _start to main() with little or no help at all. The libc-core is suffixed with the architecture name and contains processor native code for the bootstrapping to main() and a simple syscall() implementation in assembler. Among other required things, a more friendly system call wrapper is in libc-syscall, a memory manager and such in libc-malloc, dynamic linking in libc-dynlink, etc etc, each suffixed with the architecture. The dynamic linker (in theory) detects these and chooses the appropriate library for the appropriate binary. With this approach, it also becomes viable to implement POSIX and ANSI layers as well, ala libc-posix and libc-ansi containing interface compliant code relating to the other.

[Brynet-Inc]

The GNU C Library is just one attempt at creating a library that contains some of the standardized C functions, many of which are defined in the ISO/ANSI C standards.. but the bulk of the good ones are POSIX defined.. (..so don't use Solar's library. )

All the BSD projects have their own C library... with their own functions as well.. each of them try to workaround bugs and behaviour Linux application writers assume always exist.

If you're looking for alternative libraries, here's a list you could have found via Google.

http://www.fefe.de/dietlibc/
http://www.sourceware.org/newlib/
http://www.uclibc.org/
...
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/

Does this answer your question?

[whowhatwhere]

It seems syntropy is under the impression that glibc is the best and only C library in existence.

The GNU C Library is just one attempt at creating a library that contains some of the standardized C functions, many of which are defined in the ISO/ANSI C standards.. but the bulk of the good ones are POSIX defined.. (..so don't use Solar's library. )

All the BSD projects have their own C library... with their own functions as well.. each of them try to workaround bugs and behaviour Linux application writers assume always exist.

If you're looking for alternative libraries, here's a list you could have found via Google.

http://www.fefe.de/dietlibc/
http://www.sourceware.org/newlib/
http://www.uclibc.org/
...
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/

Does this answer your question?

I know a lot about the other options, however, they don't fit my uses or preferences, and more or less just redo glibc "their own way".
Dietlibc is nice, but it's not licensed in a way that benefits the projects that I work on for the linux userland.
Newlib is not something I've tried as a glibc replacement, because it is still as flawed as glibc is in the manner I described above.
uClibc has issues with both licensing as well as threading and it's failures to build. It's a mess, and it still has the same problems as I described above.

As for the BSD libcs, I haven't had much of a time to get into the BSD userland, as I've always used Linux. I won't even attempt to criticise something I haven't used before.

[Solar]

I think I made a mistake. I apologize to Solar...

Accepted.