On 28 Mar 2022, at 2:28, Warner Losh wrote:
On Sun, Mar 27, 2022, 8:15 PM Kyle Evans <[email protected]> wrote:
On Sun, Mar 27, 2022 at 2:01 PM Bjoern A. Zeeb
<[email protected]> wrote:
Hi,
I am building on a stable/13 machine (updated a few days ago but I
had
that before in the last months).
I have git clone and am mostly working on main or main-derived
branches.
Once in a while I switch in-place (not a worktree) to a stable
branch,
e.g., git checkout stable/13 based on freebsd/stable/13 for MFCs.
When I do that and start to build an amd64-only universe my kernel
builds immediately fail with a dubious error message from a
top-level
Makefile:
# nice make -s -j30 tinderbox TARGETS=amd64 [..]
make[2]: ".../freebsd-src/Makefile" line 731: "Target architecture
for
amd64/conf/LINT unknown. config(8) likely too old."
I tracked it down to the profile 2 line sys/amd64/conf/NOTES which
makes
config fail apparently.
When I apply the below change things work flawlessly.
I do not fully understand where the problem comes from, but given I
haven't seen other reports I wonder what it is that I am doing that
makes things go wrong here?
Anyone an idea?
Whoops, we ripped 'profile' support out of config(8) so now it can't
config older kernels.
Where did that happen? Oh, I see it in “main” a year ago. I
couldn’t see it in stable/13?
I think the cheapest/easiest fix would be to
just re-add the keyword as a nop so we can still parse it, maybe emit
a warning that it's been removed in newer config(8).
Yea. It would be trivial to do so. But what about the version issue?
config is a bootstrap tool. So the real problem could be that when I
switch branches from main to stable/13 it is not rebuilt and so I get
the version from main which then fails on stable as it no longer knows
how to handle “profile”? Or something like this?
I see 1 config binary in two directories in a freebsd13-amd64/ subtree
in my obj dir (5 days old). One directory is ${HOST_OBJTOP} so first in
path for this call in Makefile. Sadly we don’t have idents ..
Seems to be a build system problem and not a config problem of some
sorts?
Note that my builds in this case are not using WITHOUT_CLEAN or similar.
I am trying to figure out how to force a rebuild of the freebsd13-amd64
obj subtree to see if that really makes the problem go away..
/bz
