Date: Thu, 30 Mar 2023 19:30:15 -0700 From: Mark Millard <marklmi@yahoo.com> To: void <void@f-m.fm>, Warner Losh <imp@bsdimp.com>, Current FreeBSD <freebsd-current@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: 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') Message-ID: <2E3300BE-5D37-4476-B0CB-7D0ECAE06957@yahoo.com> References: <2E3300BE-5D37-4476-B0CB-7D0ECAE06957.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E3300BE-5D37-4476-B0CB-7D0ECAE06957>