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

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


Looks like I can not avoid also dealing some with "run". I
was trying only to deal with "build".

I'll get "run" out of the way first. I do not think it is
relevant to what I was referencing but that may not have
been clear.

A somewhat older user-space runs on newer kernel in a supported
manor. But for newer user-space running on older kernel there
is more risk. Some environments even complain:

QUOTE
Poudriere version: 3.2.8-23-ga7f8d188
Host OSVERSION: 1400073
Jail OSVERSION: 1400084
Job Id: 01

!!! Jail is newer than host. (Jail: 1400084, Host: 1400073) !!!
!!! This is not supported. !!!
!!! Host kernel must be same or newer than jail. !!!
!!! Expect build failures. !!!
END QUOTE

Some FreeBSD package builders operate this way much of the time
(main package building) and sometimes suffer for it. But it
gives a away to discover unexpected ABI/semantics breaks and
avoids having to update the server kernels as often.

I'll note that building releng/13.* packages do not get the
complaint because the Jail user-space is earlier (by version)
than the host (the host normally being some main vintage):

QUOTE
Poudriere version: 3.2.8-23-ga7f8d188
Host OSVERSION: 1400073
Jail OSVERSION: 1301000
Job Id: 01
END QUOTE

The Jail uses the older user space and its older toolchain,
not the toolchain from the Host (main). The main/Host
kernel actively supports this use of the older user space.

[This context too can end up with discovering an
ABI/semantics break. I was somewhat involved in the
discovery of one of these breaks fairly recently for
the package builders. Main got an update to avoid
13 and before from running into the problem and the
package builders got the updated main kernel so that
the later package builds that had the problem would
go back to normal. The issue was not a toolchain
issue in this case.]


How this mixes with "build" in my context . . .

I've used poudriere-devel on main [so: 14] to build for
stable/13 and releng/13.* but the poudriere jails had and used
the older user-spaces and the older user-spaces' toolchains,
not the toolchain from main.

Similarly, I've used chroot areas on a main system to have
areas for stable/13 and for releng/13.* . Again these have
the older user spaces and the older user spaces' toolchains
in use inside, not use of main's toolchain.

(I've not been doing virtual machine activities so I'll
stick to referencing things analogous to what I've done.)


So, given that much context for reference . . .

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.

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.

May be having the chroot/jail/... is a big enough issue that
some effort is put to avoiding needing to have a older user
space around. But I'm not aware of such and have certainly
not done such. (I ignore here various odd things I needed
to do when doing my early powerpc* clang related
investigations before the PowerMac's died. Such was
definitely not in the realm of supported activity.)

> It's something we try to keep working... on a best effort basis.


I'm not sure if that wording is about "run" vs. "build"
vs. both. I was only focused on the user-space and toolchain
vintage involved in the build, not about the kernel vintage
that code was run under. I worry that my note got taken in
a different way than I intended, making interpreting
responses messy.


===
Mark Millard
marklmi at yahoo.com