Thank you so much! This is exactly the kind of information I was looking for. In my experience I only rarely interact with hard links. GCC is a project I hold in very high regard, so I was curious to see if there was a strong reason to use one or the other. > Hard links are faster. Hard links are more efficient. I figure that dereferencing a symbolic link (at least to a file on the same physical disk) will be orders of magnitude faster than almost anything you'd want to do with g++ once you find the inode. If you have a filesystem hierarchy with no links or bind mounts, then it forms a tree (rigorously, in graph theory terminology), which allows you to make certain assumptions during traversal. Symbolic links are clearly distinguished from ordinary files, so we can add those and still do fast traversal. To the best of my understanding, hard links on the other hand require us to keep track of all inodes with link count >1, so we can detect cycles. I'm still admittedly in the very early stages of this line of inquiry, but I believe it could have applications in functional package managers like Guix and Nix. I have some ideas for fast traversal with hard links, but it would be easier without. > If you want to have GCC optionally use symbolic links here, implement > that, and send a patch? This is a great idea. It would be perfect for my purposes. Thank again, Jack
