On 11/24/25 2:00 AM, Kito Cheng wrote:
Another approach for fixing this:
https://patchwork.sourceware.org/project/gcc/patch/[email protected]/
On Tue, Nov 11, 2025 at 11:03 AM Kito Cheng <[email protected]> wrote:
I found that the title might be misleading, so I’ll fix it in v2.
The problem actually also occurs when the input is a preprocessed file
(e.g. .i or .ii).
$ riscv64-unknown-elf-gcc x.i
cc1: error: /home/scratch/build/install/riscv64-unknown-elf/usr/local/include:
Permission denied
cc1: error: /home/scratch/build/install/riscv64-unknown-elf/include:
Permission denied
I may have stumbled over this at one time or another in the last few
years since the scenario you describe (build in one path, relocate to
another) is standard procedure for our internal releases.
This occurred because the GCC driver did not pass GCC_EXEC_PREFIX and
isysroot to cc1 in the compile stage when using -save-temps, causing
cc1 to search headers from the wrong (original build) path instead of
the relocated installation path.
The fix ensures cc1 is aware of relocation by passing %I (which includes
isysroot) and setting the GCC_EXEC_PREFIX environment variable.
Seems like a clear bug to me.
{"@cpp-output",
- "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}}", 0, 0, 0},
+ "%{!M:%{!MM:%{!E:cc1 %I -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}}", 0, 0, 0},
I'm a bit leery of this hunk. As you noted we've already indicated the
code is preprocessed, so we shouldn't need/want %I here. It seems more
like this should be fixed downstream.
The rest looks OK to me.
Jeff
