Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 07 May 2026 16:05:45 UTC
On 5/6/26 19:59, Mark Millard wrote:
> On 5/6/26 09:07, bob prohaska wrote:
>> On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote:
>>> On 5/6/26 07:50, bob prohaska wrote:
>>>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote:
>>>>> On 5/5/26 17:32, bob prohaska wrote:
>>>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote:
>>>>>>> On 5/5/26 07:48, bob prohaska wrote:
>>>>>>>> A Pi2B (armv7) is failing buildworld with:
> 
> Which is true of the context:
> 
> ) Is the old system one still using the llvm19 based clang related
>   toolchain --so that the build needs to bootstrap the llvm21 based
>   one?
> vs.
> ) Is the old system one already using the new llvm21 based clang-related
>   toolchain --so that no bootstrap toolchain is needed (even if one is
>   being built)?
> 
>>>>>>>>
>>>>>>>> Building static clang library
>>>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of 
>>>>>>>> the file: e_shoff = 0x131190
>>>>>
>>>>> How big is the ParseDecl.o file that gets this report?
>>>>>
>>>>> </usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o>
>>>>
>>>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o
>>>> -rw-r--r--  1 root wheel 393216 May  3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o
>>>
>>> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 .
>>> That is a lot bigger than 393216.
>>>
>>>>
>>>>>
>>>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming
>>>>> one long line and are not part of the file path.)
>>>>>
>>>> Including the < and > in the pathname triggered a syntax error. Likely I 
>>>> misundersood the tip or I'm using a different shell. 
>>>
>>> Only use the text inside the <>'s.
>>>
>>> The <>'s are an attempt to prevent the message I send from splitting the
>>> long text into more than one line in the process --even if I do not
>>> split it myself. Otherwise you might have to splice together the full
>>> path. Adding spaces just inside the <>'s would not work for the purpose,
>>> thus the lack of such spaces.
>> Ahhh, so user escapes, not shell escapes 8-)
>>
>>>>
>>>>
>>>>>
>>>>> Can you publish the content of the file:
>>>>>
>>>>> </usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse_ParseDecl.o.meta>
>>>>
>>>> The file has been placed at
>>>> http://www.zefox.net/~fbsd/rpi2/20260506/
>>>
>>> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta .
>>>
>>> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I
>>> expect it will include the text of the command that produced
>>> ParseDecl.o .
>>>
>>> Like earlier: omit the <> characters when extracting the path.
>>>
>> Apologies for the blunder! The correct file is now at:
>> http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta
>>
>> Thanks for writing, and your patience!
>>
>> bob prohaska
>>
>>
> 
> My guess is that, for an initially empty build tree in a armv7 context,
> a command sequence like:
> 
> # cd /usr/src/
> # env WITH_META_MODE= \
> make -j3 \
> WITHOUT_SYSTEM_COMPILER= \
> WITHOUT_SYSTEM_LINKER= \
> kernel-toolchain
> 
> may be sufficient to have:
> 
> </usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o>
> 
> generated instead of skipped, via avoiding use of the system
> compiler/linker, even if they are llvm21 based already. (In my
> context they are llvm21 based, as it is a preexisting upstream pkgbase
> distribution install from after llvm21 was updated that is doing the build.)
> 
> I have such a llvm21-context build going in an armv7 chroot (in a
> context were -j8 is reasonable). Still, it is going to be some time
> before I know if the build repeated the problem vs. not.
> 
> It may be that one has to start with an llvm19-based context to see the
> problem. I do not have such a llvm19 context available.
> 
> 

Bob sent Email that was not sent to the list that reported his context
upgrade context is starting with an environment that has:

QUOTE
Clang -v reports
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git
llvmorg-19.1.7-0-gcd708029e0b2)
Target: armv7-unknown-freebsd16.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
Build config: +assertions
END QUOTE

My test case was llvm21 based, no bootsrap needed --but when Iforced a
boostrap, llvm21 boostrapped itself just fine.

Thus, it looks like the armv7 llvm19 context has a problem that prevents
source code building the llvm21 bootstrap context correctly.


At this time I do not have an armv7 llvm19 based context to
independently test.


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