Date: Tue, 6 Feb 2024 17:24:17 -0800 From: Mark Millard <marklmi@yahoo.com> To: Brooks Davis <brooks@freebsd.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> 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 ? Message-ID: <62F9061D-1033-4CB8-8B5F-FA88A9160FED@yahoo.com> In-Reply-To: <ZcLSad0PuLY-bAHa@spindle.one-eyed-alien.net> 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> <ZcLSad0PuLY-bAHa@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 6, 2024, at 16:44, Brooks Davis <brooks@freebsd.org> wrote: > On Tue, Feb 06, 2024 at 04:22:51PM -0800, Mark Millard wrote: >> On Feb 6, 2024, at 15:11, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> On Feb 6, 2024, at 15:02, Mark Millard <marklmi@yahoo.com> 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 = <http://libllvm-18rc.so/> >>> Sorry for the confusing additional notation: >>>=20 >>>> <http://libllvm-18rc.so/> >>>=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 = <http://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 "\<rc\>" /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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62F9061D-1033-4CB8-8B5F-FA88A9160FED>