Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement]

On Sat, May 09, 2026 at 04:43:29PM -0700, Mark Millard wrote:
> On 5/7/26 17:50, Mark Millard wrote:
> > On 5/7/26 16:46, bob prohaska wrote:
> >> . . .
> > 
> > 
> > I'm still no closer to having an idea what else to do for investigation.
> > So far, you have the only known example failure context.
> > 
> > 
> 
> I've only had one idea for a very limited test sequence, based on
> referencing the Parse_ParseDecl.o.meta file:
> 
> ) Start from a status of already having the bad Parse/ParseDecl.o in place.
> 
> ) # cd /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang
> 
> ) # mv Parse/ParseDecl.o Parse/ParseDecl.o.bad
>   (Or analogous. Below presumes that name I listed.)
> 
> ) Execute the:
> 
> # c++  -O2 -pipe . . . -o Parse/ParseDecl.o
> 
> command listed in the Parse_ParseDecl.o.meta file.
> 
> That command is long enough that simple copy/paste might split the line
> up into multiple lines. (I've run into such things in various contexts.)
> So care to get the command right/complete may be needed.
> 
> The questions for the results are largely based on comparison/contrast
> with the original bad file:
> 
> ) Does the command or the console report some sort of message that might
> be relevant? If yes, what are the details, otherwise conintue.
> 
> ) Are Parse/ParseDecl.o.bad and the new Parse/ParseDecl.o the same by by
> size and (most?) content? If yes, you have replicated the problem and
> report that. (There could be timestamps or uninitialized pad bytes or
> such complicating the content judgment if the sizes are the same.)
> 
> ) Is the new Parse/ParseDecl.o big enough compared to avoid the prior
> error messages? A simple command that would report the too-small size
> problem would be something like:
> 
> # readelf Parse/ParseDecl.o
> readelf: error: 'Parse/ParseDecl.o': unable to continue dumping, the
> file is corrupt: section header table goes past the end of the file:
> e_shoff = 0x131190
> 
> If it does not produce such an error message, then things are very
> different. The file might even be correct to continue the build with.
> Report the status.
> 
> 
> At some point you will likely want to delete Parse/ParseDecl.o.bad .
> 

It looks as if running make kernel-toolchain somehow worked around
the failure. It completed successfully and is now running a normal
buildworld, which is in the building libraries stage. 

Hopefully it'll finish within a day or two.

Thanks for writing, apologies if I jumped the gun!

bob prohaska