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

On 5/7/26 12:24, Mark Millard wrote:
> 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
> 
> 

My attempt at reproducing the problem (small ParseDecl.o file) still got
the full sized ParseDecl.o result (1295860):

# ls -lodT
/usr/obj/usr/src-alt/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o
-rw-r--r--  1 root wheel - 1295860 May  7 13:16:25 2026
/usr/obj/usr/src-alt/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o

This was based on an environment doing the build that has:

# clang -v
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

# ~/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)


I diff'd the c++ command from the .meta files and only found the "-alt"
used in /usr/src-alt/ references in my context. Removing the -alt
examples from my text found no command differences as a result.

Complete .meta file comparisons also found process ID differences and
time differences but otherwise matched.


I still have no clue what is going on in your environment that leads to
the small ParseDecl.o file.


How old is your environment that is using llvm19? What commit is it
based on?


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