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 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.

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.

>> 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