Re: Odd stoppage in buildworld

On 7/5/26 17:32, bob prohaska wrote:
> A Pi2 (armv7) is stopping meta-mode buildworld in -current, reporting
> 
> ...
> Building /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm.a

arm.armv7/tmp/obj-tools/lib/clang/libllvm/ indicates that it was
building the bootstrap toolchain.

arm.armv7/lib/clang/libllvm/ is where it would be for the normal
toolchain build building.

Is this build the one that switches from llvm19 to llvm21 based?

> Building static llvm library

As I understand, the defaults are now:

) the bootstrap toolchain is built statically linked

) the normal toolchain is built dynamically linked.

(I override that last for my contexts.)

> ar: error: libllvm.a: 'InstrProfWriter.o': section header table goes past the end of the file: e_shoff = 0xc6c24
> *** [libllvm.a] Error code 1

It would be good to see the ar command that produced that message. At
this point there is some guess work in expecting that it was generating
libllvm.a instead of using it.

The related paths may not be obvious :

tmp/obj-tools/lib/clang/libllvm/ProfileData_InstrProfWriter.o.meta
tmp/obj-tools/lib/clang/libllvm/ProfileData/InstrProfWriter.o

Note the _ vs. / before InstrProfWriter.o* .

Have the two *InstrProfWriter.o* been regenerated (new modification
date)? What about the pair of files (no ProfileData directory involved):

tmp/obj-tools/lib/clang/libllvm/libllvm.a
tmp/obj-tools/lib/clang/libllvm/libllvm.a.meta

Does tmp/obj-tools/lib/clang/libllvm/libllvm.a contain a copy of
InstrProfWriter.o ?

> 
> Deleting the offending .o file didn't help, running make clean in /usr/src
> didn't help, running make cleandir in /usr/src didn't help.
> 
> This error follows a kernel panic during buildworld, so I'm guessing
> that has something to do with the problem, though the machine finished
> fsck on reboot without obvious difficulty.

Incomplete buffer flushing by a crash need not prevent fsk operation,
even though the file am be incomplete fro its purpose.

> 
> Removing /usr/obj seems the next thing to try, but that's going to
> be slow. Is there a more efficient approach to salvaging the system?
> 
> It's at
> root@www:/usr/src # uname -apKU
> FreeBSD www.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #46 n287176-a2545f68f64b: Thu Jul  2 11:47:19 PDT 2026     [email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600019 1600019
> 
> Thanks for reading!
> 
> bob prohaska
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com