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.

cracauer@ · 2026-02-09T02:01:20+0000

Yupp, that was it. mod_os.h is unique to the broken tree and has a modification date of April 27, 2025, which is roughly when this machine was active last. Are you on BSDCan? I would like to buy you a beer.

My mistake was to blindly assume (and state in the OP) that the src trees were identical because I pulled them at the same time and did `make clean`.

That is related to a thing I know about `make clean` but rarely adhere to: if you first pull a new git version and then do a `make clean`, then you will not clean things that are no longer mentioned in the new tree. You need to do `make clean` before updating to do a precise job. That's probably at the root of what happened here.

If I had looked closer at the `cc -E` output on the first iteration I would also have spotted it. But that view was very convoluted and I postphoned the second iteration.

atax1a · 2026-02-09T02:12:15+0000

did it not show up in git status? (how well does that work on src, anyway? back at Ayectototlan they operated a git fork to deal with the huge monorepo)