GCC built!

A while back, I posted about how I was trying to get GCC to compile on Astral and how I seemingly hit a wall that I had no idea on how to start debugging. Well, a few months ago I decided to give it another try after I spent some months working on other things in the kernel. It actually managed to not segfault! I dont really know exactly what fixed it, but if I had to guess it was a VMM bug I had fixed while I was porting QEMU.

However, there were still some issues after that which needed to be fixed in order to finish the compilation and even a small bug during make install relating to docs. I slowly worked on it over a few months and now I will be talking about them in the order which they happened during the build process, as well as talk about what is next for full self-hosting in Astral.

Libgcc failing to configure

After the compiler itself finished building, the support libraries started being built. During libgcc's configure step, it ran into an issue where the script couldn't build a program:



This happened because it was trying to get the as program from a script the GCC configure step created and the path in that script was empty. At first, I thought it was because Binutils was installing files in a way the configure script couldn't recognize. I later discovered that, in Astral, test -x would return 0 for an empty path, which obviously was not the correct behaviour and it affected the checks for as.

Fixing that involved changing the behaviour of the VFS path lookup function, vfs_lookup. If it was given an empty path, it would just return the start directory, which caused access(2) to return a success for the permission check. This is due to test -x checking if the executable permission bit is set, and directories use it a lookup permission bit.

Libstdc++ header issues

With libgcc built, it continued the build process until it hit a compilation failure on the C++ standard library:



Looking around, I discovered that this bug happened due to three issues with symbolic link handling, one in mlibc and two in Astral's ext2 filesystem code.

The mlibc issue was in the realpath(3) function, where, in the absolute path case, it would unconditonally discard the last character, which I assume was to handle a trailing / in the path. With that fixed, the other two issues were related to the ext2 opimization of small symlinks, where it stores the path directly in the inode if it is small enough (shorter than 60 characters). The issue was that, in the driver code, I included 60 character long paths in that optimization.

A successful compilation

After that, there were no more bugs during compilation and it successfuly finished!



The whole process took quite some time, which I blame mostly on the slow I/O Astral currently has. It helped uncover quite a few bugs on the kernel and userspace, as well as testing the stability of the operating system. With that done, all that was left to do was installing it.

Installation doc fail

The last issue I hit and the most easily fixed was a fail while make install was doing something doc related.



Looking at the GCC prerequisite pages, it lists Perl as one. It is used for generating some documentation and I dont have Perl ported. My solution for the problem was to just patch that line out, it is not nescessary for the compiler to run and userspace documentation is not a priority at the moment.

A working compiler!

After taking some time to install due to the slow I/O, it finally built! It was able to compile a working hello world program, and marks a huge step on the way to being fully self-hosting. While I was debugging the libgcc issue, I also found out that Binutils successfuly builds too, which means the whole toolchain is able to be built inside Astral.

What's next?

With the toolchain done, there are many options of what to do next with regards to self-hosting. Currently, there is a QEMU port which, once fully working, could be used for testing changes to the kernel. Another way of testing changes to the kernel would be to install it directly into the boot FAT32 partition which Limine uses. However, there is currently no FAT driver in Astral. When it comes to uploading changes to the internet, there is a working Git port that has been used once to push a small fix as a test.

What I will most likely do next is try to build mlibc in Astral. This will require a port of Meson and Ninja and will really test if the Python port works. This will only be done after I do a lot of the changes and optimizations to the kernel I have planned, however.