From nobody Fri Mar 31 02:30:15 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PnkmB1L6rz42kxW for ; Fri, 31 Mar 2023 02:30:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pnkm83hF6z3pZ2 for ; Fri, 31 Mar 2023 02:30:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pf8EZVkW; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1680229830; bh=wcGBAp1so25Q0JIUYQTPTNyI7PToI/ZeWcClwtajKJ4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=pf8EZVkW4r8vHTJMn6XxfQTaBL9h749ymrny3GFnG+VdMbC2y/FR1vi3VSLHV93I+fb4uCLEl03pTmE1i3afGr2Qnx8bm1VH9aWqj+rVvSG87s00LsSnzCZ5IKgDC4C8SZDjYdrqDJ0R8vEsI7xFK9LoEDxgchsdjuLdXEo54EP4MRSEIfxeA+jMkF14gkUg3jh64mzqSuHZUIBkJSeHc5Ymd98N4OemriRNBJIBWMwqYygybd5mtvCUoANMTZ297id/finfWiuwx1FqJo74nEEOdkZOGOySPmZoQMH+nWkf4Ji1q/5Vr0LDFLbllqMG2DqPJsJbCjUHIQtGJpOtOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1680229830; bh=dfiRToyJKl1uqKegxZHukolrFFUcyStBGlD5k2DwAIK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f45PBnM5lqTrQDjrM0ucHnBcjDQsdfcCjxnqkRaJnaX/SEV/zkIYNglQ99C+HF/LIK2sRA+WTFwYru9yzRtY6NF8QxPobPH0FyZcn7ozcMtNdQyKV7Ym6qL9a9jP+LivtCctbpDEMCGZpwfrDH1V3OuyUmbhQfxuF7ty8c9kw+RVHp1ElE5EPUkBB0qLizyYUoLllqZmtWUCicw5DgrM5SvjCypipijpqLvxDu+25o18+3Yur17J8p1mKWDUFqxnvYfEsN0kH0Mh8+uJQ6JfwaoZXvA00It4zS3a+0VO9j+njVBMUqw0TYTTEtZjQrptPpfGkJIgKctGf7rBIH4Lzw== X-YMail-OSG: BCA5IAUVM1n.l3n4Y_zOU7yZ2brUieeGN1hJGIV1dXJAvz5hzSWl4nB4tXVrowM _ZbixVKQJJBeAnPaIk3HmbZDDbt5XhEh4Vk8NUuybAiROStPEqpUGC9QO_oGSMuFw63Vw7Q9xtxa cEmBwNEVbYcuyDkPW57V_gbTexCCY8d8ApmLnKa6weoAkFMXBWGs3g83D5MIRAxuXNLgej2K7MND JCzAYJRiluOrMIcKnqw_uArLFIBmIHwUuVpx6ZP27AfVLtySiE9KbqysJyVWR3xlskIOc_G.BgCK r68t5jN7C6tnsTrJLNobQP30vVzv4YYK66cukGY9rM8p5EoSEZ.Hsxj4l7Dk0ZD7F6YzRddGWCeR Vjfbq0lK54rTrlfrOkNjdMMvCrugdt0xMVj34CFoWWgh6rWaTnpCOwb9snzwva6lKXGc3GTAB4h0 O8RiB88H.GjMilByKgaCoVDfApnL_rPSiL2mtP1_2NK2tTbM2ycPnIzul2ccRFRzwzluaRLUZUTZ IbXi.5WuvcxlMmmQcuVYBEtlrNjPQ64RVFWg8H3AjUOP1EJYTdI.obutpKF1_.bsgKdg2N8jloU4 9Kt2B1X3YjIYdbZLbuk5zeUSTH2NoeEvLPmAroUupKDKnszSAlkaBDqiqd.0vlZgO2SHoLBNmI.C PneZQ3nDwh4NRP3Hg3r1_PvMbgvDxh7UkQwCUegvFf4r7qfJ06AJbBJzo1RRLWSny0BS5hcBuRaU w4ZkT7a7lrGN_OayVJ9mEvGTsQYHlrkwWx90F4u4E6KQ8TrJxrdEVuerHigUEvhI.hEgg50eb4JJ cLIHhV8g_vWiozB_wEiUmwxgt.CZVd6ZVEApt124A1i_7Lz47BuLIJ4YL8jPLLtIZOAedjCoPUVX ztTkCsveyFP6uCHVpLTL1gsG2REUBfhLv2zeNY2cixhKtBk2NpqJmMkMhXpEOHzxZRGLCIQu0iSc KhKIm67dkKZclUjSBQG6YGkNxdzdsMmm987B_2rFDVpkgCrWanMTNEwHLy_x_bGqUKpIiTKLGfrs WtZXNcp4BSE.jHpCaj2JFegixRmTdofahka.mthOfxGWqqfPZA8HEFNpPWCd_H4D91N5nLTJ.Hzq IR24rPxJiQUm9gC1zGWqSJoTVN3L8bjcB10sNeiIGymT9pMh7H9Vg1U42OJTO4hsde2lsj9hv5m7 F5rAaMfL4EFVKwTRJoLwd10mRYeIrnL1FfhH0uOFScrnGuqyWQG9Ub97C_ZUi24YpdhVym5zVwR9 lRSLiW54ehOTUDZVquEkZtVUeMlRyDYgftfRkEEsRlApXRwuy13vcJAGAwkIPDQNxxEZ4lIuRR_R JeRjaqWFMInsaM1EyL1DfohyuiuTgxf2Jwd1JQcpEq4SOzpPxnpJb0o2Tsa4CFuR8wzXAlS8cNqh 9Ez81FntpS3MTIdryCXLfhbjqe6gKTf3iqzJUDmdZswYslafGVuf0r1C82hMePHBjJxOrZWZ9Y8e jDS73sLhUGs_.ClVhCw8nJf__gB34QUlFhfjBYM107srtmmJFxsf9c2KNMfpb8.1Vr1SoS6PA3bW uuBQ5GjmVfJq32C5H6YJq7f9VNSP81qksjCcFsms9CXV5hcgkBZCHbC7gXc4frBMnB5F.tYuwcah LmpYZkGmaiJSNRlVRnxeMWQxHfTzpTCKaKRiOOGg8OL_fAq4Xg1AsWaUfidDybFtt156AXh6588m 8JDAz7ns2xEXWcjkRI05rcA6_cG_2IOiOSvtvA9IZ0wWr6IHQzFSEbXQNxqEMAzDvN0yp6UUNIhZ uFKl.TFLLakmOQmQNflwhawrdHQh0mU_19L6wXs55VkCF576JC_J5cGj_W9fAN16SWPu9hDi3JP4 HiTBRDzB_J8o20lgmDZbtAXVk.M6R4DXWzRrHrW9KvdZuJetT4nyIyO4ohYSXxEgCn1X2DjMn4EZ LnN6NCjeAzzHCGZ3qJ42c4ytIb9CNWzquSPE4NPuGTpLMPB9E3JombkEQO_Y5IYYrwgFtAqt5hJP 8K9QzWW4w70HICkK.l7kp_Ppa1ypVZuSV74o4dbgeCcVkDWTw.NTh8I7gT.lC3ZqDBcS9.y5GD9e 4lFjHB5v.uDc6qXInXnhJ3Q9XNhGE_Xy1WjH7oeDX5RLd0brio9BkA1ks3sZrCrNI5WxJdhlPKG4 TAEsuiMC8VHMQbnE7IGOpVg24mJ3d0kUPTGCRbKrfIEJjBlYzWKrtvFNzk1gwPrc8W14twesicUk 6FB_J8g9zsqimMUABDBlvkXlvQpSel.nvjNU5F2dYmoe76UlfbIV84cvZFFOARbqtEv0NwOcG3_U - X-Sonic-MF: X-Sonic-ID: 61fee54f-046b-4e3a-a4cd-adad6d95ac9b Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Mar 2023 02:30:30 +0000 Received: by hermes--production-ne1-7dbd98dd99-qthmr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cd52814d0dcf0aa4805d23060004b85c; Fri, 31 Mar 2023 02:30:26 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) 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> Date: Thu, 30 Mar 2023 19:30:15 -0700 To: void , Warner Losh , Current FreeBSD , FreeBSD Toolchain X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <2E3300BE-5D37-4476-B0CB-7D0ECAE06957.ref@yahoo.com> X-Spamd-Result: default: False [-3.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.964]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[f-m.fm,bsdimp.com,freebsd.org]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4Pnkm83hF6z3pZ2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Thu, 30 Mar 2023 22:15:38 UTC : > On Thu, Mar 30, 2023, 3:45 PM void 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