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 01:17:48PM -0700, Mark Millard wrote:
> On 5/13/26 12:26, bob prohaska wrote:
> > 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.
> 
> Ahh, the likes of something like the sequence:
> 
> cd /usr/src/
> git pull
> buildworld
> git pull
> If wanted, go back to buildworld
> buildkernel   if appropriate
> installkernel if appropriate
> reboot if kernel was installed
> installworld  if appropriate
> reboot if world was installed
> 
> I was definitely attempting to answer the wrong question.
> 
> The last git pull could delete things or otherwise change the operation
> of installkernel and installworld that would happen, Makefiles having
> changes to match teh updated source tree. So avoiding that would be part
> of your "if wanted, go back to buildworld" judgment.
> 
> And, suppose the 2nd git pull did something like the llvm19->llvm21
> change. Would you actually want to try to avoid the big change until
> later --with the mismatch in place? Instead looking at the changes
> elsewhere, such as via:
> 
> <https://lists.freebsd.org/archives/dev-commits-src-main/YEAR-MONTH/date.html>
> or:
> https://cgit.freebsd.org/src/log/
> 
> would seem better than updating your live /usr/src/ to no longer match
> what you might install.
> 

For my level of understanding it appears that compiling after pulling
is the only reliable way to ensure consistency of the install binaries.
Directory-level makefiles are a particularly sensitive spot since I
can't predict which source files might be affected without reading and
understanding the Makefile and all that depend on it. 

> Another option could be to note the commit from the earlier git pull,
> and after the 2nd git pull that you do not want to use, cause a
> detached HEAD pointing at the prior pull's commit. Before the next pull,
> you would need to restore to be using the 2nd pull's HEAD, if I remember
> right.
> 
Trying to work commit-by-commit seems like a good way to get lost. The
introduction of commit numbers is a great improvement over the hashes,
from a human point of view, but I gather git can't use those numbers 
to select what to fetch and compile. In that respect svn was nicer....

I got started on this path by being minute-wise and became hour-foolish.
Time to mend my ways 8-)

Thanks very much!

bob prohaska