From nobody Wed Feb 07 01:24:17 2024 X-Original-To: freebsd-ports@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 4TV2Tc6kjPz58NGr for ; Wed, 7 Feb 2024 01:24:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4TV2Tb6C7Cz49Kk for ; Wed, 7 Feb 2024 01:24:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707269073; bh=lowLC90WoSSfcfgSrtEmH2eUmiWkKfsZQ5AXoAnqqUI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QVXHr4OmQnLfC+H51EesKnq7rU7cQuhXSSYN9q1X7zJX0gyScrNuoZdA+YMvacyewojxAP0zESOpi2CMtaD0T2Up4eCU+CM2QhE7LIY4W4tbjsdGeueCCA1NS+VzbKzFETfaR1pDl148WCbwYXQYcqsBajLY0/bqnUXaUkh2CydI09UPrfkfpObyvvZ3xbrIALbGF4774HvG9gspNaMs1afIdwVGvPda69djAlEyBqbVTQRBdm1iuSgirnCcv6nTx1rSXpP1C/wZS2y6Z/rnks8oUbBdYfqH0GBL4GwL6a7ohu4JOOuEhvtIvX+waFpBGLg7TYOIrxa2pojTV6sokA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707269073; bh=uPdPKI83i1RTuWvb1PxPj9GsmLNMn4f901VzvqnFmQf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Dq59rHcueo2DJqAzVTY8C8n0pFEwFSexS3ghT3gRsVXdmeBmPVkHJkzgPRhy+JjtBPrsKDLJheDTT3VpjCQLxkjCELazOsEnLqT9xkqqTUp66F9YQXS4jHRa15+XmsA5j4bpwIUPpAOAFjkhweJj+Ri8A0RBCsSPdCw+atUxlYpKURC0gkbsnfAKycjaiouXG49WOSpOK7FbJSk4Ai8ZhfxcegQi0fw/4+MDV7BUEcg7REgdDMalgQMNlagGj03KNtvHGFOhfzB9TZq98JFfguOcUkefMNoeFpa+NkiPx5btBQI4N2BAAVGnSQvIhkOKsWf0nGIMIOwacUd7QQ5TUA== X-YMail-OSG: Lrrspl4VM1nzbOoeT_iYamqeqVnE8e1.n3WoicYA6t2BU._cne17nfiyglt4pkv 0P00CpeDbKM93Ayq3hBaT19a9zHpHJN7r2xEy26_msgWNE1OG_05swbs4lHnoOt1BOnPeUkkPKUa Hw4PUaH8Z5J7QNjaS3DaAwQdWVbxIlyfx6QsgqBZGxnvuvfBXNC8.rEF34TRNVXP7W_GthE1IpOG 7thbio87yKIdOcIOQHW8qHzGDxXJV1n1IJbmszLtb5658sSunirV5bchIZPqQm_IwsNV9GQ0xcQA bErrxcOOPSIUhNN1TIn2g34dpTXFiAddyR1ConOPaSe2obt58TxjdzCjFlUPgFEjh2EC5zGL6TSW ltOCO9UIK0MuadSfCpz_XpX8xvtS.U8NFx5MTj4Y1h6l8CkBCjRB5DcurjAk0jbMmLd3d91hYG5K dg97slaCY5WK3gUS0VZBiD.ZrMtWgnb7b9jgDogtjd0UWuUt0TSc9bVN0i.VRdtycdEAxP8P7_i9 OPCE04Yxt_O2p5U4LvXbH7OKfdaP2aLe784tCZCPj3oD3sF4UbtMxaMeBgL5J_PwDp3Bg3Wx43a1 etyzxv.ZX66zSbaOJ1TuSbe8ubp43CbMnt6q9wUMeB_E3gN6dGtkm0yX6IMW4fSEqaD83C8dGBRE O4cJe_Ony.D8gTu.RLMYrgVZj4LS4_N9CaH8JDcfhBUr_EUlEPVddzKUOsJnnnY3Gp5eagAm3Txt fQy0Wf4zGc7ny5ejDEgdVXpdPm8dP90RcOaxYzWId8PJYFZOx1cuj1yFgYK89L4SRA1pScrDzKxD qaWR4mvM6P69R3X9lH_IkElEQf5ENpDU7ZFRXHp011sFD3FOoyXPqtXefSuQ6Y3NSM9NnJvlywJQ oXX7P3WbgdxDjW_Ejjl4zQQwFEiJ_M1QbyuEVg768dRj9tszfYeqPZQjsm77DkrICYsqrt9bHwXx _InpmhF1rBG8WRkQVx5mQAGZHJKNK43ZLwFUIWZDd3GLwyJroevR8TAqjk07wt_vJELLu_Vhn8NE xf__b0Ii6eSIjJ1MSCqJERX2nA2pqai6rO_wtQLkwbhpklAUy5VBHHF967f3NoC3OF8ucqYbaC0U MFbdnhdWiwY0kGLlNXhEyRlXCv7KbxEz5gS_iGBO.7YXUGvXL1LBQFMQW8D1khdwwfcAah.7FN1g B5gJbqWm1I0w747N_bcytm12GqPjZ_s5xrN.99.9Np90_YvCl5VFv8zHnEVsCE5p9W9pHrwWwO.8 LBs_fQanxi0roq_6bGgZ5YDK8FhfUL8sixugX9iXovqrGJD8.FoDIidDQcIkXnAdJGK_QtSznYLJ EUKNqP3QTR6avjlC_YJZqdGlPjMdM_7ltdMVqtOElQniDWd8g2n2w6xzD7.uXfPG76Z6uc3dL3Ay .L5o682FRFgN2WLNiWSnTtcVk6epvOlNHIwmJ7VvQd2m5UvQtWaVXTY64pJ1inA_Tm73q5CRL.Yw nZppZa8gm5cTgPK11l1em5SW9.Oq3dkrnGO83vgVDd6fLHCZRTCB.H0ygUit4b8QcQSEX9CXaNMP s6KqFtFsNj.DEmeq7uyS0lQbFkNVan4Mvys6eF58U8obQmFBBL9wENzI0ezWtiVaHjz30hF3CM.k vfnnY2Xh1yFHJmPjDEN5QLLdKRAhhcaIzP5fdRrBr8hhrVl6JXyAUrA.Bx9c0hwdCnYk4_HBUMqD RZwWmhBvYScgviqHHR7Fck2e0gK25sqVAfIUzuULqu.gSVB25fox8P4EKmiz_kGkbfCmdtJ28IWL wIDXRemzQC3ivXpIDU7YvEALWoKW8N1k6Fk2ZdGrvh7QDMyQ2BEqdy87qIa8kT1KMaIk54bjt76b IahjEPfzIPOiAxlWfY6D2HJpXXO1.TSRn3I2mOFvws08I46o7ZqJOZD_3QwEScnwRTjjlBExJwaj QSL1tj0XwaUzSVUk1OSO46V6.Uua2W94KcKiJGHz7zJXPTWunAMUA7VDu8xjd_dhSbtpzbUqmUrC hYTszxYOAL9Z1ml2NVzuZ_S5lGVaQnPeWyQnCn._pEQGJ3_AQNSU8R4Jt_2eccaJHGxeHX82KTis i09IhcH5oYxUpw7xu57FxvKfAc.qpr.lZEyYi6UBINCqogQcCkfk4uYKT28Rfx54sxFddnv0kTV_ .F9v6i0DIEvMJtzzthOsKG3uY_oReT89hPHsGowyx88r2tUtVGSDbOTkeYlpIcniWsJHUvlWYyTX E0DKHXqlK1OxrXKGTSos9EcSJZs.zFfb_SYJQRHSlgw3vSW3xbddh4zD85HZsI0ZA2lDPrGH2v4o koBITj8IeJ.V8DlOAsZmF X-Sonic-MF: X-Sonic-ID: bf3c737c-afee-4d15-b051-7810f1e90504 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Feb 2024 01:24:33 +0000 Received: by hermes--production-gq1-5c57879fdf-9nrfh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 64c62926797b3fa2838ee453242cee44; Wed, 07 Feb 2024 01:24:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ? From: Mark Millard In-Reply-To: Date: Tue, 6 Feb 2024 17:24:17 -0800 Cc: FreeBSD Toolchain , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <62F9061D-1033-4CB8-8B5F-FA88A9160FED@yahoo.com> References: <78C3797B-BCA5-4FFA-A14E-8A3135DAD95A.ref@yahoo.com> <78C3797B-BCA5-4FFA-A14E-8A3135DAD95A@yahoo.com> <71F86B94-6D27-4CE4-8FD5-321538DAB6EF@yahoo.com> <4FCDBDD8-183F-47D6-A35D-6B4AC042B7B7@yahoo.com> To: Brooks Davis X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TV2Tb6C7Cz49Kk X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Feb 6, 2024, at 16:44, Brooks Davis wrote: > On Tue, Feb 06, 2024 at 04:22:51PM -0800, Mark Millard wrote: >> On Feb 6, 2024, at 15:11, Mark Millard wrote: >>=20 >>> On Feb 6, 2024, at 15:02, Mark Millard wrote: >>>=20 >>>> Using BE_STANDRD, I built llvm18 as part of a poudriere >>>> bulk run, which resulted in: >>>>=20 >>>> # ls -Tlod /usr/local/llvm18/lib/libLLVM*.so >>>> lrwxr-xr-x 1 root wheel uarch 15 Feb 6 13:34:30 2024 = /usr/local/llvm18/lib/libLLVM-18.1.0rc.so -> libLLVM-18rc.so >>>> -rwxr-xr-x 1 root wheel uarch 138305928 Feb 6 13:30:11 2024 = /usr/local/llvm18/lib/libLLVM-18rc.so >>>> lrwxr-xr-x 1 root wheel uarch 15 Feb 6 13:34:30 2024 = /usr/local/llvm18/lib/libLLVM.so -> libLLVM-18rc.so = >>> Sorry for the confusing additional notation: >>>=20 >>>> >>>=20 >>> that showed in in the E-mail. I had not noticed at the time that >>> the mail program was helping me in that way: it was not deliberate >>> on my part. >>>=20 >>>> But later in the pooudriere bulk run when mesa-dri tried to build >>>> it complained about not finding libLLVM-18.so = : >>>>=20 >>>> [amd64_ZFS] Extracting llvm-18_1,1: .......... done >>>> =3D=3D=3D> mesa-dri-23.3.5 depends on shared library: = libLLVM-18.so - not found >>=20 >> The following suggest more names that might be problematical >> in devel/llvm18 as thigns are --and includes the *rc.so one: >>=20 >> # grep "\" /usr/ports/devel/llvm18/pkg-plist >> bin/llvm-rc%%LLVM_SUFFIX%% >> llvm%%LLVM_SUFFIX%%/bin/llvm-rc >> llvm%%LLVM_SUFFIX%%/lib/libLLVM-%%LLVM_RELEASE%%rc.so >> %%CLANG%%llvm%%LLVM_SUFFIX%%/lib/libclang.so.%%LLVM_RELEASE%%rc >> %%LLDB%%llvm%%LLVM_SUFFIX%%/lib/liblldb.so.%%LLVM_RELEASE%%rc >=20 > This comes from upstream and will change with the release: >=20 > = https://github.com/llvm/llvm-project/commit/22683463740e55e7e0d7e664395c30= 899b229205 >=20 > I wonder if mesa is inappropriately hard coding the library name or if > there's a cmake file issue that should be resolved upstream (those > generally seem to reference static libs though). >=20 > $ llvm-config18 --libs > -lLLVM-18rc >=20 Looking at /usr/ports/Mk/Uses/llvm.mk it does not seem to deal with the "rc" naming unless _LLVM_MK_VALID_VERSIONS has the rc listed. Picking the .so notation handling as an example . . . _LLVM_MK_VALID_VERSIONS=3D 10 11 12 13 14 15 16 17 18 will not produce _LLVM_MK_LIBLLVM with an rc via its notation: libLLVM-${_LLVM_MK_VERSION}.so unless _LLVM_MK_VALID_VERSIONS is instead: _LLVM_MK_VALID_VERSIONS=3D 10 11 12 13 14 15 16 17 18rc In turn: _LLVM_MK_PATH_lib=3D ${_LLVM_MK_LIBLLVM} LLVM_LIBLLVM=3D ${_LLVM_MK_LIBLLVM} LLVM_VERSION=3D ${_LLVM_MK_VERSION} would not have rc for the just "18" case. There are other problems like comparisons, such as: . if ${_LLVM_MK_CONSTRAINT_min} > ${_LLVM_MK_VERSION} where if _LLVM_MK_VERSION and/or _LLVM_MK_CONSTRAINT_min contains the rc the result is possibly not as desired? So is: _LLVM_MK_VALID_VERSIONS=3D 10 11 12 13 14 15 16 17 18rc the intent during the rc stages? Does that really work? =3D=3D=3D Mark Millard marklmi at yahoo.com