mlibc - an existing libc with similar goals to LLVM libc

Runtimes C
1

Dear,

My name is Geert Custers, a core contributor to mlibc. mlibc is a fully
portable C library, written in C++. The library has a design focus on
portability and modularity, it is as platform agnostic as it can be. We
have a Linux port as well as many other hobby OS ports. Hobby OS's are
not the primary motivation for mlibc, but the ports serve as a
compelling demonstration of the portability and modularity of mlibc.
While learning about the LLVM libc project, it occured to us that the
goals of mlibc and LLVM libc are almost exactly aligned.

Given our common interests, it seems beneficial for both mlibc and
LLVM libc to possibly collaborate. As we speak, mlibc has a variety of
POSIX/Linux/ANSI features implemented, and we are able to run a large
collection of Linux/POSIX programs, such as XOrg, Weston, GCC, Clang,
GNU Bash, GTK2 and 3 and many more. We accomplish all this while still
remaining fully portable, assuming very little about the host syscall
interface. Some notable features include a dynamic linker, and an
incomplete, but extensive pthread library. However we are still missing
many things, such as for example an implementation of POSIX regex.

We would be very interested to hear your thoughts on a possible
collaboration.

With kind regards,
Geert Custers and the rest of The Managarm Project.

2

Dear,

My name is Geert Custers, a core contributor to mlibc. mlibc is a fully
portable C library, written in C++. The library has a design focus on
portability and modularity, it is as platform agnostic as it can be. We
have a Linux port as well as many other hobby OS ports. Hobby OS’s are
not the primary motivation for mlibc, but the ports serve as a
compelling demonstration of the portability and modularity of mlibc.
While learning about the LLVM libc project, it occured to us that the
goals of mlibc and LLVM libc are almost exactly aligned.

Given our common interests, it seems beneficial for both mlibc and
LLVM libc to possibly collaborate. As we speak, mlibc has a variety of
POSIX/Linux/ANSI features implemented, and we are able to run a large
collection of Linux/POSIX programs, such as XOrg, Weston, GCC, Clang,
GNU Bash, GTK2 and 3 and many more. We accomplish all this while still
remaining fully portable, assuming very little about the host syscall
interface. Some notable features include a dynamic linker, and an
incomplete, but extensive pthread library. However we are still missing
many things, such as for example an implementation of POSIX regex.

We would be very interested to hear your thoughts on a possible
collaboration.

tl;dr - The development LLVM libc is under the LLVM umbrella in the open. That makes LLVM libc also open for collaboration by default :slight_smile:

That said, it will help if you can elaborate more about what you mean by “collaboration”. LLVM libc is in early stages. However, few downstream users have already started using the parts available in production. Our focus areas for the near future are the pthread library, stdio and finishing the math library.

3

Dear,

My name is Geert Custers, a core contributor to mlibc. mlibc is a fully
portable C library, written in C++. The library has a design focus on
portability and modularity, it is as platform agnostic as it can be. We
have a Linux port as well as many other hobby OS ports. Hobby OS’s are
not the primary motivation for mlibc, but the ports serve as a
compelling demonstration of the portability and modularity of mlibc.
While learning about the LLVM libc project, it occured to us that the
goals of mlibc and LLVM libc are almost exactly aligned.

Given our common interests, it seems beneficial for both mlibc and
LLVM libc to possibly collaborate. As we speak, mlibc has a variety of
POSIX/Linux/ANSI features implemented, and we are able to run a large
collection of Linux/POSIX programs, such as XOrg, Weston, GCC, Clang,
GNU Bash, GTK2 and 3 and many more. We accomplish all this while still
remaining fully portable, assuming very little about the host syscall
interface. Some notable features include a dynamic linker, and an
incomplete, but extensive pthread library. However we are still missing
many things, such as for example an implementation of POSIX regex.

We would be very interested to hear your thoughts on a possible
collaboration.

tl;dr - The development LLVM libc is under the LLVM umbrella in the open. That makes LLVM libc also open for collaboration by default :slight_smile:

That said, it will help if you can elaborate more about what you mean by “collaboration”. LLVM libc is in early stages. However, few downstream users have already started using the parts available in production. Our focus areas for the near future are the pthread library, stdio and finishing the math library.

Hi Geert,

Thanks for reaching out!

Like Siva I would be interested in knowing if there were particular areas of collaboration you were interested in. The licenses between the two repositories are not compatible, so we can’t do direct sharing of code. But some thoughts that come to my mind are more about information sharing; e.g.

  • Understanding what each others’ main use cases are
  • Understanding what pain points each of us have encountered
  • How we approach testing and validation (e.g. “Here are some tricky things we’ve found you have to deal with when you are validating double-precision math libraries”)

Basically things that fall into “If you are building a libc from scratch, here are things that get encountered along the way that you need to think about.”

Regards,

4

Hi,

Is this the repo?

https://github.com/managarm/mlibc

Most of the places that I'd expect to contain code contain a dummy.cpp that contains a single stub. That doesn't match what you say about the support, so I assume that I'm looking in the wrong place. Can you point to the correct locations?

David

5

Dear Siva and David,

Thank you for your responses!

We would like to port managarm to LLVM Libc, though at the moment, this
is not possible. The biggest barrier to this being portability. However,
as far as we can tell, portability is one of the goals of the LLVM Libc
project. We believe the mlibc codebase can help with this, as we have
quite some code already in place, and we also have this code ported to
many different smaller OSes developed by hobbyists (our portability
probably being our greatest strength).

What we imagine a collaboration to look like is something akin to the
following:
  
  1. We work out how to port additional OSes to LLVM Libc, with a
  portability model that fits our purpose.
  2. We contribute a managarm port to upstream LLVM Libc.
  3. If this all works out, we could re-license some parts of mlibc,
  and contribute a lot of our code.

However, we’d only like to continue with this if our portability &
modularity goals are aligned. For example, one thing that’s extremely
important to us is supporting a wide variety of OSes, no matter how
small or large, it’s fundamental to mlibc. With a portability-first
philosophy this should come naturally. Another big feature is
modularity. In mlibc different libc standards (such as ANSI C, POSIX,
glibc and Linux extensions) can be turned on and off by the user. These
are important features for us, and they make mlibc such a unique and
flexible libc, so if these are not met, then it would be difficult for
us to envision collaboration.

On the other hand, if we can agree on goals, and a good way forward,
then we believe that there is an opportunity to make LLVM Libc a mature,
portable and modular libc that can be used on a diverse set of OSes.

We would be excited to hear your thoughts on this.

Best, Geert (on behalf of the managarm team.)

PS: I’ve also put some relevant members of the mlibc team on CC.

6

Hi David C.,

Is this the repo?

That is indeed the correct repo!

Most of the places that I'd expect to contain code contain a dummy.cpp
that contains a single stub.

In mlibc we include all additional libraries (such as libm,
libpthread, etc...) in the actual libc.so file. However, to maintain
compatibility we need to still emit those libraries. All those
dummy.cpps are just for generating those libraries. All the actual code
of the libc can be found in options/*, along with sysdeps/* for the
sysdeps.

Regards,

Geert