byteduck/duckOS

[SUGGESTION] Improved LibC

PF94 opened this issue · 6 comments

PF94 commented

Suggestion

One of the issues

While attempting to port QT1 (at https://github.com/PF94/qt1, until i nearly entered X11 hell), the building process falls apart at the beginning due to a lack of an access function in unistd.h.

image

https://man7.org/linux/man-pages/man2/faccessat.2.html

Good idea. libc compatibility is something I've been chipping away at as issues come up while porting other software (which, as you can tell, I haven't done much of). I'm focused on stability for the time being, but this is definitely on the roadmap.

PF94 commented

i'm still trying to figure out what things to port to duckOS, it appears some of the stuff I'm interested in porting either doesn't support cmake or they require a lot of dependencies.

Yeah, porting new apps will require a lot more libc compat work and a build system. We would probably either fork them and use submodules or store them in the monorepo as a patch file.

PF94 commented

i believe serenityos' port system uses patch files, right? also for legacy things like qt1 i think a fork (which i did lol) would be better than multiple patch files.

PF94 commented

also this might be required in order to actually have LibM? I tried to port some LibM implementation from another OSdev project with the same license and it kept reporting missing functions (and header files such as endian.h).

I've added stubs for a bunch more stuff, and implemented the access(2) syscall. I'll just close this for now, since improving libc is always an ongoing battle :)