Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF

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.


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