Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')

void <void_at_f-m.fm> wrote on
Date: Fri, 31 Mar 2023 13:18:34 UTC :

> On Thu, Mar 30, 2023 at 07:30:15PM -0700, Mark Millard wrote:
> >Warner Losh <imp_at_bsdimp.com> wrote on
> >Date: Thu, 30 Mar 2023 22:15:38 UTC :
> >
> >> On Thu, Mar 30, 2023, 3:45 PM void <void@f-m.fm> wrote:
> >>
> >> > On Thu, Mar 30, 2023 at 12:56:53PM -0700, Mark Millard wrote:
> >> >
> >> > >To my knowledge, FreeBSD has not actively supported newer
> >> > >FreeBSD building older FreeBSD across versions.
> >> >
> >> > Are you sure? I routinely build & run 12.4 and 12-stable bhyve and
> >> > poudriere jail instances on -current.
> >> >
> 
> >Do you use main's toolchain to do your builds of releng/12.4
> >and stable/12 ? The first time? Their updating builds? As far
> >as I can see use of main's toolchain means not using an older
> >user space (via/in-a chroot, jail, etc.) to do the builds.
> 
> I don't know in detail about the toolchain. When 12.4 builds on
> -current, the screen shows it bootstrapping, and I guess this is for
> 12.4.
> 
> The reason I commented on what you wrote was because your assertion
> appeared to me[1] to be incorrect, in that logically following on from that
> assertion would mean 'don't expect it to work because it's 'not 
> actively supported' meaning that it's 'unsupported'. 
> 
> But I can't contextualise 'actively supported' into 'should work' or
> 'expected to work' given Warren's comment about 'best effort basis'.
> 
> I build poudriere jails for 12.4 on -current like so:
> 
> 1. git -C /usr/src checkout releng/12.4
> 2. poudriere jail -c -j 124Ramd64 -J12 -m src=/usr/src -b -v releng/12.4
> 
> To update:
> 
> 3. git -C /usr/src checkout releng/12.4
> 4. git -C /usr/src pull --ff-only
> 5. then I have to delete and build the jail as in [2] otherwise it'll
> complain about wrong objectprefix
> 
> is this workflow incorrect?

I do my own system builds in a directory tree, such
as /usr/obj/DESTDIRs/13_1R-CA72-poud , and then have
pourdiere(-devel) null mount such to run its jails in
for, in this case, releng/13.1 port building on a main
[so: 14] system.

So I'd need to investigate some to figure out for sure
if there is anything odd about your sequence but the
delete and build from scratch I'd expect to automatically
do a bootstrap toolchain build and then use that build
for the later activity that actually targets releng/12.4 .

> >A sequence can be bootstrapped by starting from materials for
> >a pre-built release or snapshot of the older user space and
> >then update via its internal toolchain. My understanding is
> >this is the actively supported way, not building older
> >user spaces directly from a newer user space and its
> >newer toolchain.
> 
> It appears to me[1] to be building its own toolchain and building within
> that. The ports it builds work on the machine it's built for, without
> errors about things like ABI etc. I don't do any pre-building, and am
> unsure if the poudriere jailbuilding process does anything outside of
> the standard build process.
> 
> [1] non-expert in any of this!

So it looks to me you are building normal bootstrap toolchains
and such via normal procedures. My original note was split
in 2 parts: building/using bootstrap toolchains vs. otherwise,
with the bulk of the text being just about the "otherwise" case:

QUOTE
I'm unclear here. Is the goal that a system clang 15+ toolchain
can build just the bootstrap toolchain and such that are then
used to actually build stable/13?

Otherwise I'm unclear on how compatibility with what a system
clang 14 toolchain would produce is established.
. . .
END QUOTE

Most anything in the "otherwise" material was not intended to
apply to the bootstrap case: very different contexts.

By contrast, I was not so worried if building and then using a
bootstrap toolchain was the intent (instead of direct use of
the newer toolchain for everything). I could not tell which
case(s) were the intend coverage for what I was replying to.

So, overall, I think that you just went in a different direction
than I was trying to go in the "otherwise" part of my original
note.

===
Mark Millard
marklmi at yahoo.com