Note to distribution packagers

chibicc is now distributed in mainstream Linux package systems. It came to my attention that several distros package exposed a side effect of chibicc's method to search compiler-supplied headers:

https://github.com/rui314/chibicc/blob/90d1f7f199cc55b13c7fdb5839d1409806633fdb/main.c#L52-L57

Searching relatively with dirname() works fine for in-tree execution, but when the main executable is moved and executed from $PATH, (what installing typically do), dirname() returns "." instead [1], causing chibicc to search ./include first even for standard headers.

The quirk can lead to subtle compile errors, as demonstrated by the simple Dockerfile below: the current chibicc build from Fedora/Debian/Ubuntu package would mistakenly include the ./include/stdio.h file as if it was /usr/include/stdio.h, and prints out the wrong message.

## Pick a distro

#FROM fedora:42
#RUN dnf install -y chibicc gcc
 
#FROM debian:12-slim
#RUN apt-get update && apt-get install -y chibicc gcc
 
#FROM ubuntu:24.04
#RUN apt-get update && apt-get install -y chibicc gcc

COPY <<EOF /work/include/stdio.h
int puts(char *);
#define puts(_) puts("puts hijack")
EOF

COPY <<EOF /work/hello.c
#include <stdio.h>
int main(void) {
  puts("hello");
}
EOF

WORKDIR /work/

RUN gcc hello.c -o hello_gcc
RUN chibicc hello.c -o hello_chibicc

RUN ./hello_gcc | grep hello
RUN ./hello_chibicc | grep hello

It's commonly agreed that issues only occur in packages shouldn't be the upstream's concern (and this is outside of chibicc's intended scope as an educational project), however it's probably not a coincidence that the initial packaging from Fedora, Debian, Ubuntu, Arch AUR (as well as Alpine's of my fork) all exposed the same quirk. I hope posting the issue here could reach more packagers interested in chibicc.

[1] POSIX manual:

If the pathname does not contain a '/', then dirname() shall return a pointer to the string ".".