Fix #1: Add GCC 15/16 include paths for modern distros#5
Fix #1: Add GCC 15/16 include paths for modern distros#5figitaki wants to merge 1 commit intoanthropics:mainfrom
Conversation
Systems running Fedora 43, Ubuntu 26.04, and other recent Linux distributions ship with GCC 15 or 16. The hardcoded GCC include paths only covered versions 10-14, causing the preprocessor to fail to find compiler-provided headers like stddef.h and stdarg.h. Changes: - Add GCC 15/16 paths for x86_64-linux-gnu (Debian/Ubuntu) - Add GCC 13-16 paths for x86_64-redhat-linux (Fedora/RHEL) - Add GCC 15/16 paths for cross-compilers (aarch64, riscv64, i686) - Reorder paths newest-first for efficiency on modern systems Fixes anthropics#1
Review: APPROVE ✅Clean, minimal, low-risk change. Adds GCC 15/16 include paths for Debian/Ubuntu and Fedora/RHEL, reorders paths newest-first (sensible — first existing path found is the newest GCC), and adds cross-compiler paths for aarch64, riscv64, and i686. No tests needed — purely additive static data (filesystem path strings). The existing 🤖 Reviewed with Claude Code |
There was a problem hiding this comment.
Hardcoding include paths. We will be replaced in 6 months. Vibe coding is the future.
There was a problem hiding this comment.
you don't understand, hooman, eventually it'll build a map of all possible paths on all possible machines and then it'll be able to compile "Hello, World!" everywhere!
|
Is this a problem with the cutoff date of information available to the model? GCC 15 was released on Apri 2025, model cutoff date in May 2025. |
| "/usr/lib/gcc-cross/aarch64-linux-gnu/11/include", | ||
| "/usr/lib/gcc-cross/aarch64-linux-gnu/12/include", | ||
| "/usr/lib/gcc-cross/aarch64-linux-gnu/13/include", | ||
| "/usr/lib/gcc-cross/aarch64-linux-gnu/16/include", |
There was a problem hiding this comment.
This assumes a x86-64 host, if running on an arm host, these paths will not work, the correct paths should be /usr/lib/gcc/*.
|
On my system /usr/lib/gcc/x86_64-pc-linux-gnu > x86_64-pc-linux-gnu ls
14.3.1 15.2.1So the paths should probably not be hardcoded |
|
does not work on NixOS |
… arithmetic, NEON QA Checkpoint 2 fixes: - Issue #1 (MAJOR): Wire linker script SECTIONS placement into x86 linker pipeline with segment-level virtual address adjustment - Issue anthropics#2 (MAJOR): Wire linker script MEMORY region placement via explicit-only location counter addressing - Issue anthropics#3 (MAJOR): Wire PROVIDE symbol generation and ENTRY resolution into linker pipeline - Issue anthropics#4 (MAJOR): Implement full IFUNC support pipeline: parser -> AST -> IR -> codegen -> assembler -> ELF writer -> linker. IRELATIVE relocations in .rela.dyn for dynamic executables. - Issue anthropics#5 (MAJOR): Normalize digraph %: to # in preprocessor before directive detection - Issue anthropics#6 (MINOR): Fix complex float multiplication with proper (a*c - b*d, a*d + b*c) formula via type-based dispatch - Issue anthropics#7 (MINOR): Fix complex division edge cases with Annex G §G.5.1 recovery for F64/F128, simple division for F32 - Info #1 (INFO): Add 8 missing signed integer NEON intrinsics (vaddq_s8/s32/s64, vsubq_s32/s64, vmulq_s8/s16/s32) Files modified: 22 (20 Rust sources, 1 C header, 2 C test files) Unit tests: 711 passed, 0 failed, 6 ignored Integration tests: 64 passed, 1 known out-of-scope fail (tail_call)
7 participants
Summary
This PR fixes issue #1 where hello world programs fail to compile on systems running recent Linux distributions (Fedora 43, Ubuntu 26.04, etc.) that ship with GCC 15 or later.
Root Cause
The preprocessor's hardcoded GCC include paths only covered versions 10-14. When
stdio.hincludes compiler-provided headers likestddef.handstdarg.h, these are found in GCC's internal include directory (e.g.,/usr/lib/gcc/x86_64-linux-gnu/15/include/), which was missing from the search paths.Changes
Reproduction
Before fix:
After fix, on systems with GCC 15/16:
./target/release/ccc -o hello hello.c ./hello # Hello from CCC!Notes
This is the minimal fix - just adding the missing paths. A more robust long-term solution could involve dynamic detection of GCC versions via globbing or querying
gcc -print-search-dirs, but that's a larger change.Fixes #1