Date: Thu, 7 May 2026 09:05:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-current@freebsd.org, dim@FreeBSD.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21] Message-ID: <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> In-Reply-To: <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> References: <afoDUSr7xeYIeL64@www.zefox.net> <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <afqMIyNQGtJpRQGS@www.zefox.net> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <aftVNo1vagUO9Xjs@www.zefox.net> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <aftnPgIVu6KNaAro@www.zefox.net> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7e29fc11-9fcc-4a71-97bb-b709862e35e1>