From nobody Thu May 7 21:33:13 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gBQTs65Pdz6c1fg for ; Thu, 07 May 2026 21:33:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gBQTq2VBvz3XyD for ; Thu, 07 May 2026 21:33:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bD3hNUkl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778189595; bh=gr5XPMby40+73MZJ8JjBH60WmX9xdyhO5lrCbXAgGR0=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=bD3hNUklxjuPQnObaYfESKZAcK/Nd13DKVpJ+VjYRFSHd3U6wusSaFdO4N+PG7CSZRKvjUdg7MPSqVXo8Vz7ySvOp77s2UiBvFruFuRY/ZItrxnvJyS1/Vmks41TL9hgMkstwSyT2EZnfDj0/kJ5vvP3sdE3kBvsNgeTncuw+HEgsFWK8yqUcuc10n8srXSS2GK/Av/hJr7W5nSEb1e5+HJIPEIgt1zRKjCJGFrOkrSsgWnuKSdhfkNRHh1imtEOWYx35EK/PLZoV617ey7zNLUdIJBOW5pHBbOCtlyqVpiASrixAlxl6BSQxhBSIXUUmbSbBTF5RRbQHqr1KTvIYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778189595; bh=jK5MdFPwgPS+VBOZWeFUQtUUZBOHfcBWf3mfIelJB/W=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=j9MJZAfwmYgCb1xk9Uf1yDiSeHAJ1IIoR77DoGn+NkQQMJafzHNoHqqBxb6ycl65FXHMTI5RiZlEgKyEmfwASd8C17UnlT85xhoMsRuPQ8udfXwFYt7tzLH0kAPIZ4pg5RbPL3Ch4qhMn6z7x0WkF7fthXttR1fT8WUCIlMpQdPFKTqgTI9EPSflUkjYtfO2AiiR1Pp9Gnx8KLGhvzELX5RMZOesdoLOAC3l4CG3fu7diOlRaEnPQ+VPxYzqQxZkRKZziMq+Dwu+bPqhLLkJNzw8Ezv8Q6vg2sRSOmDIkus9evq0T8ugjCt4195FvTDGEB2J4h5wCSOtcrSjnwQe5A== X-YMail-OSG: vqi_mngVM1nWPulW9zIB2G9wLsS.Nlmd8GKKnWGqvmu10q5ta3EIkYGkCqffTCx CvzYaYrfmJ9GwXubfwXFCGUI2VnmuC3vAemYy3DDAPC6JHyrISI9fvtT2x0Q4gJJ6kdDuibVt5By Pu7PJO85mRu3j.mjKRgmVgnekqLy0PQwcpbyyVHiT3s4FGMzcxEQ_oUf0kg.c5_1uo47vKL_VM2A 8zRmgNup305trfFH5_79aQuzIfRfGybY5anU6_p5OXbw5hhvICekYr0cKRohd9JF_7x6Op_qRn9e UTokgdtNjmy0kjfR4FeOncnv7JkLnt6sEBQmK_E75BVMFCtKaKFaK6lUutNs8MH9TpYVWIaxicvu GE1hLdF5vGnCJQq.CcW1huXqUaqf2..2lTqS5gqEEHrgvKT3KUbBbQbl3Ym1jnasY7lm6mCrO4Hc 5sbijLwcVdr.5ZHfWCJMSrdPSeZID_YU9_gNszCr.oQe8ZRl.LnYZJV7wS4NH_RcBWQ.jgY6ZXC1 2QqVG.J0qNN6ZFgm7W7mclPHjcGbrUxdJWH8xZSEZi_XCVxWg88Vf9AqCEHsfzOU4L.M38kAJf_J nz0ffiy4ED.y524vK_82qF_Ip53Ip9gAht6YOsLAIFCQofSpcs4PoarHRREK5_i_9kIKSN7v6I0w rCghPkW3E0lqacp9lI5TTmLkgAbn8gweq22ikawjcaEgxOLPD59UaCzlxclM5HH50HTLCaD_k5Mw LBlHWMjTUumhBCDwbjXw7VmGcOLwkziwinFCsC8WZjxPNX4lnmRB9wSp95SeLDM9McKpVv8P0sSX mZ15ZmPFNLYZecvaNI0kk3z1jgq8DRWA4kFoe5bkWeVBa68ybv8jtrwWNc3YRx6lDGUZn4XsVNJv jdUF9nH9waGpygb50GLF0Pv9DzU4o2Ccg3NI6fSKwewP6I5QLs3v5WCBxJyqJWioz.qEiz3HyvGz juTe6qofzf6PrP5Hn6g72CJN7SJJhNWSyOvSQI8MxenUIagENdGOqsx6QhkfA_u.5i3bN4GgzMNN _PjtzCmE8ChIj_qHHMI67aNzuirauTmNL6tZ6cKhEgZQb9LxEk.Go8Ei0t4rgGMKefcF384rOCFu _RJ12oNnOZCIDWI6yVpVHkMj_qWduE7VZq4zLqYt8X_DWhCSDrynOXQqND_Yc4eWC9qxu9gwk23h XgcDdMutQH.cmBhVzk1yfdt3YxvkjC4Ydcz42yLyucGJgoClu0_nWclhyZhuiy6VANMXUTP7Bd8o tQMxDs58_6i07OJGkBeeyXzi1R4YQ7mOgF8r2_CF04T5MKNMYBC6A5qvxzrHrFfX_pLkX5qOAVH3 kTSYrTNLrj5J3u9E5p1cbbOq0n1NTghPQ9ViGms3UoySb5XnabkaaLoHwH04hDhncI9gNBmh77pJ z6lTgjx_iv5uiIVsoZFvEIvS7YCMharPNnAS7ijWBI_wNSjkWgKDswk_bb8WS6Lw.3J3hFY0uTJ_ 16b0e5zVz3Y8j0rdzkXMsdTG1AIiK.LllPjHyNo365.eWDinpeS6wmRgcH7_ESpeZHF9LhglCLG8 GGxgqIrHBoN2OdDWiWdc.SzLTkYoCzBs5mNu9avB6j3CPXAzJZQAxTd4g7HSo6qoqdJSqr3Lf39B kRzrbEJqT421IqmwfZ5a93n9DRPwda4AWSECHUnhLJfqmPk1dscif24hynG.LDk8ZKYqmmxAnFdw .ZizqhyQSlZQIUlmmGryJciyolKBEBkJQmCma_FG683ZHRdD0H0Q1T2Ugeo4bz8WUqBavJkjz6er KglhXCbAn1k3nUomp8PE7iMxYm3tu56mgcgDyws8N5YhOTKmKHaQWU5cX1_HyXu7WQqA8VwdjkRS jNqCXpmjOuDeEz0kD7eDdSRFDgo_S6t7l5Qh2hI14BcwBL6MBNT375cavw9mtVXcnPfTxBdOZ3.J MGs7KszSCGNNM5Z1O_SqXvkfatJP1HTMBnTdesQ7oeZOevy0DRRcyYDmbE9Z_DvYe7j0RTiuK8uh 9_fM7qjLBinjMHC8H8tT6yVzvtTeboMPn3PPMHcX_p2mlEf.wtQXNY4i8QggGlOnbqMldVKebWVk Bvjlm2TsUqu9Ivy1_Stxvqx61SLFXacE9oP3S7yH8_CBtzo7.9RMEOXlwyItcb5FD2PYpGrJzfIk FLgXKEqMGsKKyXMbF.E6lo.78v4T0znn0djIrnIqu9__4ePZII8_3t3HAcC7jUV_HfVRa4YvU9wn XITj92RpPPwvQFy5vh.RSMlakw842NkMml2dCwrVZ9fIkykpzjZDoElcUHMXgNbTKJ9tbfsJoK_x UP9vo6LHYVBJfJ7IZ X-Sonic-MF: X-Sonic-ID: fae8578e-7c06-4ed5-bd9d-7e2c9210242e Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2026 21:33:15 +0000 Received: by hermes--production-gq1-7bb7df5c46-2m55j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 260def5a76c78cdbfa26ec578540b2a6; Thu, 07 May 2026 21:33:14 +0000 (UTC) Message-ID: <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> Date: Thu, 7 May 2026 14:33:13 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] From: Mark Millard To: bob prohaska Cc: freebsd-current@freebsd.org, dim@FreeBSD.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gBQTq2VBvz3XyD 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? >>>>>>> >>>>>>> >>>>>> >>>>>> # 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: >>>>>>> >>>>>>> >>>>>> >>>>>> 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: >>> >>> >>> >>> 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: > > > > 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 > Commit: Konstantin Belousov > 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 Commit: Konstantin Belousov 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