Date: Sat, 9 May 2026 18:41:50 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] Message-ID: <af_iXtEpDcj93Von@www.zefox.net> In-Reply-To: <fa52eea4-2301-4ed8-99f6-3fa98698bd59@yahoo.com> References: <aftVNo1vagUO9Xjs@www.zefox.net> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <aftnPgIVu6KNaAro@www.zefox.net> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <ad673dfe-caeb-41eb-8be1-77d1028dba71@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> <af0kc8imCEmhJg7t@www.zefox.net> <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> <fa52eea4-2301-4ed8-99f6-3fa98698bd59@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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 prohaskahome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?af_iXtEpDcj93Von>