Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement]

On Wed, May 13, 2026 at 10:34:34AM -0700, Mark Millard wrote:
> 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:
> > 
> > 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.

The cyle is usually git pull on a running version, make buildworld, 
then re-run git pull to see if anything that looks important has been
updated over the (possibly days-long) buildworld run. At this stage
a re-run of buildworld is (relatively) quick. Once installworld has
run, buildworld is quite time-consuming even if nothing has changed.
An update to /usr/src can thus be quickly incorporated apart from clang.

> > 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.
>
 
The best I can do is look at the list of updated files presented by git pull.
If something that might be relevant (the VM system or a troublesome driver)
is listed,  immediately re-building world and kernel is relatively quick. 
When the updates appear to be unrelated features or userland programs I
don't use there's a strong temptation to run make install and reboot. ZFS
would be a good example: I don't use it and suppose, perhaps wrongly, that
changes to ZFS aren't going to affect a UFS installation.  

In contrast, any change to clang potentially affects everything and 
motivates another pass of buildworld.

That's the limit of my analytical ability....

The question seems to be: Are changes to /usr/src not yet compiled into
/usr/obj/ able to interfere with installworld or installkernel? Up to
now I've thought not. Maybe I'm wrong.
> 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