C This C preprocessor brokenness is driving me nuatz! Looking for ideas.

cracauer@ · 2026-02-08T22:32:57+0000

atax1a said:
welp. if it doesn't repro on your VM, we're gonna say give the intel box the ol' memtest.

I really don't think it is machine instability because
- it reproduces exactly the same every time
- it does build in /usr/src/release on the same machine

covacat · 2026-02-08T22:36:23+0000

CC="cc -E" make spa.o
then spa.o won't be an object file but a preprocessed file
you can compare one that works with one that does not

cracauer@ · 2026-02-08T22:48:01+0000

covacat said:
CC="cc -E" make spa.o
then spa.o won't be an object file but a preprocessed file
you can compare one that works with one that does not

Already done a first pass on that, will do a second one.

atax1a · 2026-02-08T22:59:11+0000

cracauer@ said:
I really don't think it is machine instability because
- it reproduces exactly the same every time
- it does build in /usr/src/release on the same machine

that doesn't exactly rule out machine instability though. could easily be that a specific chunk of RAM is repeatably bad in a way that the second case avoids by coincidence.

kent_dorfman766 · 2026-02-08T23:54:04+0000

I'd like to see the complete mod_os.h file and the code surrounding spa.c:11341

I can't really tell how the macro param concatenation (##) is working with the limited compiler error dump.

kent_dorfman766 · 2026-02-08T23:55:37+0000

atax1a said:
that doesn't exactly rule out machine instability though. could easily be that a specific chunk of RAM is repeatably bad in a way that the second case avoids by coincidence.

I think this is unlikely, given the way virtual memory pages are mapped to process space. I think the chance that the bad memory page always leads to the same compilation error is minimal.

My gut still tells me that it is an environment contamination problem.

cracauer@ · 2026-02-09T00:11:58+0000

kent_dorfman766 said:
I'd like to see the complete mod_os.h file and the code surrounding spa.c:11341

I can't really tell how the macro param concatenation (##) is working with the limited compiler error dump.

It's the "main" branch of the official FreeBSD source, no modifications.

https://www.cons.org/mod_os.h

cracauer@ · 2026-02-09T00:22:38+0000

Hmmm, some of my trees contain mod_os.h and others do not. What's going on?

kent_dorfman766 · 2026-02-09T00:29:33+0000

something else to consider: might some of the problem source files be auto-generated by the Makefiles...and, if the Makefiles introduce any sort of build parallelism, the internally executing shell scripts can cause a lack of necessary determinism. ie dependencies generated by internal scripts may of may not be ready when needed. I've not built BSD kernel in many many years so my comments are just WAGs.

cracauer@ · 2026-02-09T00:43:03+0000

kent_dorfman766 said:
something else to consider: might some of the problem source files be auto-generated by the Makefiles...and, if the Makefiles introduce any sort of build parallelism, the internally executing shell scripts can cause a lack of necessary determinism. ie dependencies generated by internal scripts may of may not be ready when needed. I've not built BSD kernel in many many years so my comments are just WAGs.

Yes. Right now a working theory is that an autogenerated mod_os.h is on the bad machine and not on the good ones. Apparently it is not affected by `make cleankernel`. I got a fresh git clone on the bad machine and it did build the kernel successfully now. Now running buildworld. Let's see. I kept the old git tree for further forensics.