Skip to content

merge(toolchain): port an existing libc implementation#30

Merged
d4ilyrun merged 6 commits intomasterfrom
26-newlib
Mar 10, 2025
Merged

merge(toolchain): port an existing libc implementation#30
d4ilyrun merged 6 commits intomasterfrom
26-newlib

Conversation

@d4ilyrun
Copy link
Owner

@d4ilyrun d4ilyrun commented Mar 4, 2025

LibC

No way am I implementing my own libc !

Candidates

Here are the plausible candidates for our libc implementation.

  • newlib: embedded & portable libc, built with automake
  • mlibc: modern libc by the managarm team, built with meson

@d4ilyrun d4ilyrun force-pushed the 26-gcc-target branch 4 times, most recently from 93be60e to 502b22c Compare March 5, 2025 16:21
@d4ilyrun d4ilyrun changed the title merge(build: libc): port an existing libc implementation merge(toolchain: libc): port an existing libc implementation Mar 5, 2025
@d4ilyrun d4ilyrun changed the title merge(toolchain: libc): port an existing libc implementation merge(toolchain): port an existing libc implementation Mar 5, 2025
@d4ilyrun d4ilyrun force-pushed the 26-newlib branch 2 times, most recently from 4148f0f to 678ebef Compare March 5, 2025 16:47
@d4ilyrun d4ilyrun force-pushed the 26-gcc-target branch 2 times, most recently from 4f8eea0 to 829dec9 Compare March 5, 2025 17:34
@d4ilyrun d4ilyrun force-pushed the 26-newlib branch 5 times, most recently from af4abd9 to 071a4b3 Compare March 7, 2025 10:42
@d4ilyrun d4ilyrun force-pushed the 26-newlib branch 2 times, most recently from 5e954fc to 3425a16 Compare March 7, 2025 11:35
Base automatically changed from 26-gcc-target to master March 10, 2025 17:20
@d4ilyrun d4ilyrun mentioned this pull request Mar 10, 2025
3 tasks
Newlib is a multitarget libc implementation.

This commit only adds the posibility to build it easily,
and setup it so that it can be used with our custom toolchain
in order to compile our future userland executables.

It is still missing the required syscall implementations, since most
(if not all technically) have yet to be implemented inside the kernel.
We should now quickly implement the first few ones (exit, fds, etc ...)
in order to REALLY compile our own program.
Our previous libc implementation simply included the most basic mem*
functions and such, commonly used inside the kernel. This worked well
when working with a 'bare' gcc target (no real libc), but this is no
longer the case.

This library of useful and common libc function implementations
has now been renamed to 'libk' instead.
These are now always present inside our gc target's include directory.
If someone encounters a problem with header include paths, they should
just use our target instead of the system they've installed.
The files/directories to be cleaned are stored inside a variable.
This lets the included build.mk define what should or should not
be cleaned along with their target, instead of having a big chunk
of arbitraty RM targets in the main Makefile.
@d4ilyrun d4ilyrun merged commit 32b8c7b into master Mar 10, 2025
2 checks passed
@d4ilyrun d4ilyrun deleted the 26-newlib branch March 10, 2025 17:53
@d4ilyrun d4ilyrun added type: new Implement a new feature arch: none Not architecture specific target: toolchain Features related to our custom toolchain labels May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

arch: none Not architecture specific target: toolchain Features related to our custom toolchain type: new Implement a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant