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

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
Click to expand...
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'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.
 
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...

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.
 
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.
 
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)
 
You must log in or register to reply here.
Back
Top