oddcoder
02aa400c5c
It is fact that ld.so has libc statially linked into it. Normally we wouldn't need ld.so functionality once the program is finalyl loaded, but with the next few patches, we will have dlopen which will reuse the same ld.so functionality. The problem is that it seams that huge part of the code is possible not referntially transparent. That is, it is not impossible that some of the functions have internals states. So when using the struct Linker that is initialized by ld.so's copy of libc. we must access it using the same copy even if both copies are identical. For example in dlopen if you do linker.load_library(..). That would segfault because it is using the function from libc not ld.so So I don't truly undestand why should this be needed, but after long hours of being stuck I thought maybe.. maybe that is the issue and indeed it turned out to be so.
relibc 
relibc is a portable POSIX C standard library written in Rust. It is under heavy development, and currently supports Redox and Linux.
The motivation for this project is twofold: Reduce issues the redox crew was having with newlib, and create a safer alternative to a C standard library written in C. It is mainly designed to be used under redox, as an alternative to newlib, but it also supports linux syscalls via the sc crate.
Contributing
Supported OSes
- Redox OS
- Linux
Supported architectures
- x86_64
- Aarch64