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

On 5/7/26 09:05, Mark Millard wrote:
> 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.
> 
> 

[dim@ may be interested in this point:]
I will note that the in-progress 15.1-RELEASE is based on the llvm19
related toolchain. So, later when, say, 15.2-RELEASE tries to be based
on llvm21 (or later) instead, this problem for armv7 may well repeat in
the official release sequence.


As for main, I now have a chroot based on:

<https://artifact.ci.freebsd.org/snapshot/16.0-CURRENT/f4418cf954c299fa0934f110d6f5e9d50f2d24c5/arm/armv7/>

which is old enough to be llvm19 based. It is attempting a
kernel-toolchain build based on building:

# ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/
839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make
large page allocation interruptible
Author:     Konstantin Belousov <kib@FreeBSD.org>
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2026-05-01 01:06:42 +0000
branch: main
merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427
merge-base: CommitDate: 2026-05-01 01:06:42 +0000
n285621 (--first-parent --count for merge-base)

We will see what it does for:

tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o


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