how to port glibc

[vibhory2j]

hi everybody,

i have been working on Operating System development for some time now. I learnt about the GNU C Library (glibc) recently and now i am willing to port it to my linux like operating system. I have gone thorugh the documentation on gnu.org but was unable to do anything with that.
Any help on how to port glibc, any better source for it and any suggestions.
Thanks in advance for any help.

cheers

[durand]

You're trying to do a very big task. I tried this one without success and I'll let you know what I learnt. Perhaps you will have better luck.

• Modern versions of glibc are no longer supported for anything except linux and hurd. You can read this in their README's and documents. They still have configurations available for the BSD's, odd systems, etc but they are not guaranteed to compile or work. I found this very odd and hints towards the difficulty in porting glibc.
• The layout of the glibc source forms a hierarchy of several different layers. When compilation of the glibc library takes places, it searches the top layers for a file (for example: read.c). If it finds it, it uses it. If it doesn't find it, it drops down a layer in the source hierarchy and searches there. It keeps on dropping down layers until it finds the file it needs to compile.
• So, porting is the simple process of finding the relevant file you need to implement and creating a layer above the file's original layer with your own implementation.
• There is an awesome amount of #define macros in the glibc code. When you are implementing your ported methods, you need to pay close attention to which macros are defined at which are not. This can mess up everything you do. For example, _GNU_SOURCE seems critical and you need to have it defined for almost everything.
• You need to manually edit the Makefiles and autoconf files and explicitely state which layers you need in your compilation.
• Each layer specifies depencies. For example, linux would require sysv which requires posix which requires unix, etc,etc. (Not accurate but ok)

That's it. Define your layers and dependencies. Then you need to slowly and surely implement the relevant functions in their own layers. This is a hard and long process.

The only OS project I can think of which has succeeded well is the Syllable project. I contacted Vanders, who was doing the migration from the old glibc version to the new one, for information on how to do it and he said: ( I hope he doesn't mind me quoting him )

Certainly the maintainers only care about Linux and HURD, and they only care about HURD because they have to, as an official GNU project.

... and ...

Not to make you feel worse, but it took me a good six to nine months before it really made much sense. Part of the problem is that it's pretty unique, and the hand-crafted Makefiles and Autoconf scripts don't help much.

... and he mentioned that he wouldn't have chosen glibc personally. It's just because the original roots of Syllable - which was AtheOS - used glibc that he was stuck with using it now.

There are other C libraries out there: Newlib, dietLibC, uClibc and the BSD libraries.

Good luck!

Durand.


PS: This is an extract from my website from the day after I gave up:

And so I spent a few days trying to learn how to port glibc... wow. The website says, "easy to port". I don't think I can explain how wrong it actually is.

The platform specific parts exist in a subdirectory called sysdeps and that directory tree is actually "layered". When the compilation process starts and it's looking for file.c, it looks at the top layer and works it's way down until it finds the file it wants.

So, essentially, porting would require creating a new top layer and overriding the files that would be specific to your platform. That way, when it looks for "string.c", and you've implemented a platform specific version, it will find yours first and ignore any other copies on the lower layers.

[Solar]

I can't tell about dietLibC and uClibc. But the BSD libc seems to be out of development. Newlib very clearly defines the necessary glue functions, which should be easy enough to cover if your OS is Linux-ish anyway.

I really would like to advertise my PDCLib at this point, but it will be some time yet before that will be even near completion. :-\

[srg]

I can't tell about dietLibC and uClibc. But the BSD libc seems to be out of development. Newlib very clearly defines the necessary glue functions, which should be easy enough to cover if your OS is Linux-ish anyway.

I really would like to advertise my PDCLib at this point, but it will be some time yet before that will be even near completion. :-\

For my kernel level libc (for the kernel and device drivers) I'm mulling over newlib and PCDLib, plus possibly replaing dlmalloc with BGet and a malloc() wrapper arround it.