SanderR wrote:
Thank you for your answer.
And you port GCC and Binutils by adding your own standard library to the linker script? Currently, I got a working port of FASM using this method, but I was thinking it could be a setting on my end that I needed to configure to make it all a bit easier.
Not really. I plan on writing a C library or else porting musl or something (not quite sure about that since musl is a pure Linux libc, and quite a few things depend on Linux as OS when you wouldn't think it). Then for binutils, not a whole lot of effort is even needed to compile it (as all the low-level stuff is compatible), and for GCC, I just need the right specs file. The OS interface is UNIX compatible. I don't know why you are so hung up on linker scripts, as my OS is capable of accepting all correctly linked ELF files, so I really don't care about the layout. The specs file is GCC's configuration which tells it where to find everything. But also, most of the paths and names will be compatible. There will not be a crti.o or crtn.o (those are just silly, and not needed in anything newer than ca. the turn of the millenium). There will still be a crt1.o (containing the _start symbol), and the libc will be called libc.a and installed in /lib.
Seriously, I think the hardest thing will be to rid these programs of their love for dynamic linking. I don't plan on having that at all for now (which simplifies the C library to no end), but it also means there will be nothing capable of interpreting relocations. So no dynamic libs, and no PIEs, not even static PIEs. But once that is taken care of, the rest should go smoothly, since then it is just Linux with less features.