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/13/26 09:48, bob prohaska wrote:
> Hi Mark,
> 
> On Sat, May 09, 2026 at 08:56:32PM -0700, Mark Millard wrote:
>> On 5/9/26 18:41, bob prohaska wrote:
>>> . . .
>>>
>>> It looks as if running make kernel-toolchain somehow worked around
>>> the failure. It completed successfully and is now running a normal
>>> buildworld, which is in the building libraries stage. 
>>
>> Good.
>>
>> What was the context like just before you ran kernel-toolchain? Had you
>> cleaned everything out to start over? Or was the old bad file and
>> related materials still in place? Was this jsut after doing another
>> source update?
>>
>> When you did the kernel-toolchain was it -j1 (or no -j at all) style?
>> Some other -jN ? How did that compare to prior build attempts that failed?
>>
>> Does the Parse/ParseDecl.o file look appropriately sized now? (My guess
>> is: yes.)
>>
>>>
>>> Hopefully it'll finish within a day or two.
>>>
>>> Thanks for writing, apologies if I jumped the gun!
>>
>> You have no reason to be waiting for me.
> 
> Perhaps not, but you put some thought into a reply
> that couldn't be acted on. I'm grateful for those
> thoughts! 
> 
> After make buildworld completed successfully a 
> subsequent git pull found a significant number of
> updates, so make buildworld is running again to 
> catch up.
> 
> One lingering puzzle is whether it's prudent to
> run make installworld

I presume buildworld is also being referenced here.

> following a git pull that
> finds updates which appear inconsequential, for
> example man pages, tests or unused features like
> zfs or tests. Doing so saves quite some time on 
> a Pi2. Does it introduce hazardous inconsistencies?

An option is to use git fetch and then decide if to merge --ff-only vs.
not separately based on what the fetch reports, instead of always doing
both in sequence (via git pull). That way the "not" case leaves your
/usr/src/ checkout alone. But the merge is all or nothing if, say, only
the kernel has updates of interest as indicted by investigating the
fetch output. But doing that investigation might not be something you
would want to do based on what is output for a fetch: in involves
looking up the range of commits separately and reading about them.

(Ignoring the above . . .)

The below ignores when you are testing patches for problems that you
have run into and someone has you running either information
investigative runs or bug fix tests. In such contexts of having a
problem, you should get your /usr/src/ source code and live system to be
correctly matched, likely by switching to an older commit that matches
what you are running (that you would need to know the hash for):
detached HEAD. Later you would go back to HEAD on the branch before
doing other git activities that update.

So far as I know, you do not use the source tree in any way other than
for building/installing. For example, you usually do not look at the
code to analyze it for issues that you see on the systems --as far as I
know.

main can be subject to a newer kernel and a somewhat older world not
being matched over a specific range of commits. (Development got
something wrong in the relationship that had to be fixed.) It is not
common. The goal is for newer main kernels to allow running older main
worlds going some notable distance back.

But the source tree does not even have to exist on the system for system
operation that does not involve source-fetching/merging or builds/installs.

It should normally be okay to make kernel-toolchain; make buildkernel;
make installkernel and reboot and to not update the world when the
kernel update is of interest but the world is not. Although, a kernel
update could have something new that a new world would put to use in how
it works. So sometimes you might want both just for that.

Overall: yes, you could avoid buildworld and the later installworld in
various cases.

> 
> Thanks for writing!
> 
> bob prohaska
> 
> 
> 


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