Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21]
- Reply: Mark Millard : "Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21]"
- In reply to: Mark Millard : "Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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